this post was submitted on 05 Aug 2023
673 points (96.9% liked)

Technology

34877 readers
5 users here now

This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.


Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.


Rules:

1: All Lemmy rules apply

2: Do not post low effort posts

3: NEVER post naziped*gore stuff

4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.

5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)

6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist

7: crypto related posts, unless essential, are disallowed

founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] sugar_in_your_tea@sh.itjust.works 0 points 1 year ago* (last edited 1 year ago) (1 children)

Are you talking about configuring the editor? Ideally, that's not a common task, so it really shouldn't matter much if it uses TypeScript, elisp, vimscript, or lua.

And if you're primarily using the mouse, you're missing most of the point of editors, especially emacs and ViM. The real power of those editors comes from keyboard shortcuts and combos, not from plugins and menus.

[–] baseless_discourse@mander.xyz 5 points 1 year ago* (last edited 1 year ago) (1 children)

Yes, ideally a editor would work without any configuration, but unfortunately I haven't met any emacs user with sub 200 line dot files.

I personally cannot remember more than 20 hotkeys to save my life.

Also I find the most time-consuming part of my work is actually thinking, not clicking around with a mouse. so I don't really need to spend month to remember all the hotkey just to save 2 seconds clicking. In fact, slow down and click couple buttons to commit gives me a bit to rest and enjoy the moment when I have finished a task...

[–] sugar_in_your_tea@sh.itjust.works 4 points 1 year ago* (last edited 1 year ago) (2 children)

It's not about optimizing code entry, but optimizing reading code, since you read code a lot more than you write it.

I'm not super familiar with emacs, I'm a vim person, but here are a few examples of mouse vs keyboard navigation.

Search for text in a file:

Mouse:

  1. select the text
  2. click "find in page"
  3. click "next"

Shortcut:

  1. Ctrl + F
  2. Click "next"

Vim:

  1. Type * on the word you want
  2. Type n for next, N for previous

Find matching brace/bracket/parenthesis:

Mouse:

  1. Click on brace
  2. Scroll until you find the match

Shortcut: not sure

Vim:

  1. Type %

Navigate to the top/bottom of the file:

Mouse: scroll or click the sidebar

Shortcut: not sure

Vim: gg for the top of file, G for the bottom

Go to a specific line:

I.e. If from output from a script, like a test failure.

Mouse: scroll or if you have a plugin, click on the red part (i.e. test or lint failure)

Shortcut: in VSCode, Ctrl + click on file name

Vim: G or :

And so on. Vim is optimized for code navigation, a mouse is optimized for intuitive navigation (but slower), and shortcuts kinda fill in the gaps.

If you just want to get up and running quickly, something like VSCode is a good option. That's what I did when I decided to help my team out with some FE TypeScript code, when I normally use something else. I actually installed a vim plugin for VSCode to get the best of both worlds.

But if you really want a fluid code navigation and editing experience, master something like ViM or emacs.

Oh, and I didn't mention one of the most powerful things in both ViM end emacs: macros. I use them a ton when manipulating text, such as converting JSON to a class/struct, or doing repetitive syntax changes that are just out of reach of a regex.

[–] PrometheusG@lemmy.one 3 points 1 year ago (1 children)

Proper VS Code shortcuts for the above cases...

Find next: Ctrl-f, F4

Find matching brace: Ctrl-]

Navigate to Top or Bottom: Ctrl-Home Ctrl-End

I think it's the same number of keys pressed as vim in every case.

Probably, and we could go back and forth based on features. My main point was that using the keyboard is generally more efficient than using the mouse, especially since my hand is already there.

So for software you use every day, master it. Master the keyboard shortcuts, learn how to customize things, etc. Maybe VSCode has an option for macros, IDK (I've used them with the ViM mode, so that's at least one option). Using the mouse should be a fallback, not the first option.

[–] baseless_discourse@mander.xyz 1 points 1 year ago (1 children)

You raise a valid point. Personally, I used to read and write a lot of code, but I no longer do that. I still maintain a open source project, but my job no longer involves writing code that runs.

IIRC, the most useful functionality I used to use are:

  • peak/goto definitions,
  • mouse over to peak doc and type signature,
  • find usage in project,
  • refractor the name/signature of a function,
  • real time linting and quick fix.

I am quite curious on why go to beginning or end of the file useful? Also I am not sure that the basic find/replace is more useful than find usage/refactor.

[–] sugar_in_your_tea@sh.itjust.works 2 points 1 year ago (1 children)

peak/goto definition

Plugins are available for most popular languages. I rarely need to see the type of a value, and if I want to see the signature of a function, I usually want to go to the implementation as well.

find usage

I just use grep. I'm already in a terminal, so I have all of those features available. Since I use tmux, I just switch over to another pane and run my search there. For changing the name of a function (which is very rare), I just use sed or do the change manually with vim $(grep ...) if it's more than just a name change (usually I'm changing the signature too).

real time linting

I use a plugin for that, and it works really well.

beginning or end of file useful

Beginning of file: look for an import/constant

End of file: add new function, or a shortcut to the last brace to jump to the start of the class/function. I try to keep files small and single-purpose, so it's usually what I want (jump to end and match braces).

And yeah, I occasionally miss context-aware search/refactor, but again, it's so rare that it's not a big deal. I save far more time with macros than I lose doing manual renames. If I know I'll be doing a lot of that (and usually it comes in bursts), I have VSCode installed as well. But I don't launch it very often.

My whole workflow is very command-line oriented, so using a GUI tool just gets in the way for me.

[–] baseless_discourse@mander.xyz 1 points 1 year ago (1 children)

That is valid man, we all have different workflow, hence different priorities.

[–] sugar_in_your_tea@sh.itjust.works 2 points 1 year ago (1 children)

Yup, use what works. Most of my coworkers use VSCode, and I'm the oddball with ViM (though I have VSCode installed w/ ViM extension).

Whatever you use, master it. I recommend learning some CLI editor in case you end up needing one.

[–] baseless_discourse@mander.xyz 1 points 1 year ago* (last edited 1 year ago) (1 children)

That is great advice. Vim was actually the first editor I properly learned. I find many of the keybinding very nice and useful especially for cursor movement.

I eventually moved away from it since I find I spend more time learning it than using it. I personally dont use that many feature of a editor, I find IDE features more important to me.

But I still have many global keybinding inspired by vim, like ctrl + jkhl;^ for cursor movement. They are absolutely essential for me at this point.

Hjkl is the one core ViM feature that I actually rarely use. I use Dvorak keyboard layout, so those keys are in an awkward location, so I use other movements instead.

I have just enough IDE features in ViM that I don't feel the need to switch for most tasks, and if I ever did, there are plugins that fill in the gaps.

So I guess we're just opposite sides of the same coin. :)