I never really felt faster eliminating mouse from my coding workflow. Point and click to navigate things is pretty powerful. Why some devs try to avoid the mouse?
For me, using Vim keybindings and Emacs shortcuts is valuable because reaching for a mouse or navigating menus adds mental overhead. I view the moment-to-moment practice of programming as largely being an exercise in working memory. You’re trying to hold an abstraction in your head and implement it in an existing codebase that’s filled with other abstractions and interacting parts. Personally, removing a mouse from my workflow does wonders for ensuring that all my mental resources are dedicated to the task at hand. Going mouse-lite might save a trivial amount of time in the moment, but (for me) it makes programming more seamless and natural - which makes it not only more fun, but more productive.
I am a heavy user of shortcuts and a lot of the times I don't even know what the shortcut is, it's all muscle memory. Intent turns into an action and feedback is both tactile and visual and there is usually an easy way to get back of that also with shortcuts. Using the mouse in some scenarios is like looking through a keyhole. That is not to say that using the mouse is bad all the time, because the mouse beats shortcuts in other scenarios.
To me scrolling using the mouse scroll wheel or using keyboard keys are somewhat similar. Where the mouse workflow is eating the mental overhead is aiming a fly on a small landing 200th the size of the screen thousands of times or more daily.
Try a text editor that does something for text editing, not scripting. Vim is an option. I personally used Kakoune with (almost) default config for some 3 years and I'm sure it saved me a lot of time. I never redefined default keys, they were good enough, I only added a few user mode bindings. (Although I felt a lack of some features over that time; Kakoune with no plugins is a bit too minimalistic.)
Recently I spent a few days setting up LSP and some useful plugins, now I'm going to forget about customization for few more months again.
I don't know, fill-paragraph (M-q), the sexp commands, transpose commands, upcase-downcase-capitalize commands, indent-rigidly are all built-in, bound by default and I use them a lot. And let's not forget Macros.
Shortcuts can improve your experience, yes, but not in such a fundamental way as a new model of editing.
UPD.
For example, the Emacs way of dealing with tables in markdown/latex is to have a custom plugin which will have a separate shortcut for each action one might want. As a consequence, you need to remember the keys for each of them.
Kakoune, on the other hand, gives you a language that can express most of those operations naturally. And the language is no different than the one you use for other everyday tasks, no need to memorize new shortcuts.
Give me M-q any day over gqap (or, if you're inside a multiline comment, 3gqq; or, if you're inside a multiline comment starting on the same line as code, just giving up).
Edit: though I have to admit that I'm missing 'dt.', 'd/something', etc.
There's no doubt that it's all ad hoc though. 'd/something' is doable with C-s something RET C-w, but it's already getting tedious in comparison.
> 'd/something' is doable with C-s something RET C-w Doesn't this need to be C-s something C-r RET C-w? Because C-s positions the cursor at the end of the search match.
What do you mean by ad-hoc? They seem to me be chosen and bound by default, because they are useful in practice.
> Kakoune, on the other hand, gives you a language that can express most of those operations naturally. And the language is no different than the one you use for other everyday tasks, no need to memorize new shortcuts.
Could you point me to some example?
And I am not sure if what you say about Emacs is necessarily true, you could have a minor mode that modifies the default keys to work with text tables. Org-mode's table implementation is a good example for that.
Useful, yes, but ad-hoc.
> What do you mean by ad-hoc?
I mean that in Emacs you have one ready to use action for everything you might want to do. One shortcut covers exactly one use case; if you want more use cases covered, install plugins or write scripts. M-q is an example, it formats the current paragraph. What if I want to format something other that a paragraph? In Emacs, you will need a new shortcut and a new keybinding for that.
In Vim-like editors you have some small atomic terms that you can combine to build the actions. You can have a small number of atomic terms, which can be combined in a multitude of ways and therefore cover a multitude of use cases. In Vim the gqap is not a single take it or leave it action, it's a sentence with verb gq and noun ap. If you want the verb to act on something different, you replace the ap part with something else.
Think of keybindings as a language you speak to your editor. In Vim the language has a number of words that you can combine to build sentences. In Emacs you have only a given number of ready to use sentences, and you have to memorize each one. This is a big distinction if we're talking about a text editor for efficiency, because it defines the ratio “time spent customizing” / “time saved editing”.
> Could you point me to some example?
You can cut and paste columns in Markdown tables using Kakoune's multiple selections. Like this:
- <a-i>p -- select the paragraph
- <a-s><a-;>; -- this creates a cursor at the beginning of each line
- <a-f>| -- move cursor to the next pipe symbol (selecting everything as it moves)
- <a-.> -- repeat the last move command (do this to select the column you want)
- d -- delete the selected (by each of the selection)
- <a-f>| (or <a-b>|) -- again to move cursors where you want to paste things
- p -- paste the deleted column
In this example, I haven't used a single command that I don't normally use while editing, say, Rust or Haskell. And you can manipulate Org, Latex tables with similar commands. In Emacs, you'd need a separate plugin for each of these, wouldn't you?
Kakoune.org has more videos where they show what it can do (without plugins).
You'd usually have a DWIM command, e.g. that it formats the region, but default to the paragraph if nothing else is selected. I have the feeling you are making this out to be a bigger difference than it actually is.
What I think is the mistake is that vim/kak are all just interfaces, while Emacs is software. Emacs can steal anything that any other program does, and have it combined with it's existing strengths, like the ball of mud that it is. And even without emulation modes, there is inherently nothing in Emacs that is stopping it from using the same kind of sentence mentality you are talking about (and that I am familiar with, I have used both, but prefer Emacs).
> In Emacs, you'd need a separate plugin for each of these, wouldn't you?
Plugin is the wrong word, you mean package, but not necessarily. Emacs has syntactic commands, that can operate on a major-mode specific definition of expressions, sentences, top-level definitions (defuns).
To do what you did in your example, I'd just use macros, recording this sequence:
C-a M-SPC C-s | (repeat C-s to select the column you want) C-w (again move cursors where you want to paste things) M-w
and then repeat that for all the following lines. Multiple cursors are just visualized macros, after all.
I have no doubt that what I've shows can be done in Emacs. How natural is it to express? How much scripting and packaging does it require? How much extra memorizing does it require?
> What I think is the mistake is that vim/kak are all just interfaces, while Emacs is software
Yes, I am talking about interfaces, not software. I was talking about the interface that Emacs offers by default. Of course, you can script anything in it, but it's a meaningless argument; Linux kernel allows you to implement any program you want, but it doesn't make Linux a good text editor.
And in particular, I was talking about interfaces that are efficient, take little time to setup and save you a lot of time when you use them. My claim is that Emacs is not one of them. (Which doesn't make Emacs bad in the ultimate sense. It can be good for other things.)
> Multiple cursors are just visualized macros, after all.
Yes and no. Any text editing operation can expressed in ex commands, but it doesn't make ex a good editor, and definitely doesn't make it an efficient one.
Multiple cursors give instant feedback, this is a big advantage over blindly shooting macros at your text.
> What does your sequence of commands mean in English?
This time I tested it to make sure that I say the right bindings:
1. Go to the beginning of the line (C-a) 2. Find the n'th column (n * C-s |) 3. Activate the mark (C-SPC) 4. Go to the next column (C-s |) 5. Kill the region (C-w) 6. Go to the column you want (m * C-s/C-r |) 7. Insert the region (C-y)
> How natural is it to express?
To me it is instinctive.
> How much scripting and packaging does it require?
None, these are all basic commands.
> How much extra memorizing does it require?
All you need to know is how to record a macro.
> Yes, I am talking about interfaces, not software. I was talking about the interface that Emacs offers by default.
But then you are comparing different apples to oranges? But even if we are comparing vim/kak the interface to Emacs' default interface, I still don't think the difference is that big. The main difference is that vim/kak are parts of the terminal workflow, while Emacs is a shell onto itself.
> Multiple cursors give instant feedback, this is a big advantage over blindly shooting macros at your text.
You have instant feedback while recording a macro too? You can even make it interactive, and insert a query into your macros to make it easier for you to distinguish between false-positives and the actual places you want to apply macros.
But. Kakoune is still something bigger for me. It does take text editing to a new level and it does make it more efficient. It is similar to Emacs in the sense that both follow the sequence “select and apply an action”. But Kakoune has richer selection primitives and has actions that work on multiple selections at the same time; this can be done with macros, but it's by far less convenient.
In your example, you can record a macro and apply it to all the lines of a table. Will you have to do it for each line one by one? Can you say, “run the macro on each line of this paragraph”?
> You have instant feedback while recording a macro too?
Sure, but not on all the places where you're going to apply it at the same time. And your macro may not work correctly on some of the lines, you will not see it while recording it. With multiple selections you see it immediately and can undo the last action and try again.
Multiple selections stay there after you apply actions on them. After you apply something, you can see the result and slowly think of the thing to do next with them. With a macro, you will have to type in the whole sequence when you record the macro.
Macros can achieve the same things, but they require more mental effort and are harder to get used to. And when you're focused on your code, the mental effort it takes to used your editor matters.
In the same way, multiple selections are an improvement over Vim's tradition of shooting regexes at your text; for the same reasons: interactiveness and instant feedback.
I have to admit that I have never seriously tried Kakoune. It has always been to similar but not similar enough to Vi(m) for me to work with.
> Can you say, “run the macro on each line of this paragraph”?
Yes, apply-macro-to-region-lines (C-x C-k r) does that. Of course you'd have to select the paragraph first (M-h).
I use C-u-M-q. I prefer that text layout.
I used to do that when I was young. Lots of elisp. Then I threw away a lot of customizations I didn't use anymore, added packages for the languages I'm using now and I think I ended up with a straightforward configuration.
As long as somebody isn't being a huge detractor because they refuse to use the tools everybody else on the team does I don't really care. Not even enough to engage in a discussion about it. Unless there are beers.
It just feels better for me to use. I do less squinting. :)
I notice that when I am totally in the zone, I start to get frustrated quickly when tools take longer than normal or stop working correctly. You have a map of where you want to go and have the mental acuity to do it, but when tools get in your way, it takes you out of the flow.
With keyboard commands, I don't have to verify the accuracy of my mouse movements, and I don't have to react to the timing, location, content, and focus changes of UI widgets. I just press the keys in the right order. It requires so much less vigilance, it's a big relief.
When I have my hands on the keyboard I prefer to keep them there so I use ctrl - w to close tabs, ctrl-t to open a new tab etc.
When I have my hand on the mouse I prefer to keep it there so I used to love mouse gestures on older Firefox versions at least.
What do you mean with older FF? I've been using mouse gestures for decades (Opera anyone?) and I still use the same ones today on FF. Different extension/plugin of course, but works the way it should?
Use vim shortcuts in all the programs, so you never have to use the mouse or learn new keyboard shortcuts.
For Firefox something like Vimium works well.
But I’ve recently started using a combination of Neovim + treesitter + LSPs, and have found it incredibly powerful. Extremely responsive automatic compilation that feels instantaneous, good inline error messages, very good and fast syntax highlighting through treesitter... At what it does, I’d go as far as saying as it achieves more than any other IDEs I’ve tried. But of course, what it does is more limited.
At the moment I rarely even touch a mouse. I work primarily in Vim, with DWM as a window manager and a Vim extension in the browser. When I have to work in a different environment and use a mouse again, I find the constant context switching very distracting
- https://github.com/nvim-treesitter/nvim-treesitter#quickstar...
- https://github.com/neovim/nvim-lspconfig#install
Just by following the instructions I had a pretty good setup already, but I made a couple of further changes, like setting up autoformatting on save, which was a bit trickier. `vim.lsp.buf.formatting` was useful there, but I had to do a bit of research to figure out how to use it (it wasn't immediately available on the READMEs).
However, one of my reasons is that I work out of coffee shops a lot. Not having to bring an extra piece of hardware that takes up space is a big deal for me and not taking my hands off the keys is a big deal.
I was a gamer (Counter-strike), and as precise as I believe my mouse-clicking to be, it is far less precise than the correct sequence of keystrokes to get to some parts...
Readline shortcuts available in most shells, i.e., ctrl-a (beginning of line), ctrl-e (end of line), meta-b (back a word), meta-f (forward a word).
In Vim - I can delete entire code-blocks with a quick sequence and have my cursor ready to type, and I can move chunks of code with their delimiters far more easily than my fairly precise mouse clicking and highlighting then moving my hand back to the keyboard to hit backspace. I can also switch to a "tab" (buffer in Vim) with a few keys without having to cycle through tabs or use a mouse to find the tab I'm looking for with a mouse.
There are many benefits, it's why even though text editors have come so far, people still continue to write Vim plugins for them -- think VS Code, Atom, and all the IDEs that Jetbrains produces...
Now that I know how to enable it for specific modes, I'll definitely be using it for visual mode, and maybe insert mode (we'll see how much that annoys me). Now I'm off to see if I can get the mouse wheel to work at all times but click to place cursor off except when I want it, which would be ideal.
Deleting selected text works if you're in line-editing mode. It could be made to work in normal char mode, but it's a bit tricky.
Setting mouse-reporting by the application (emacs, vim, mc, etc) works pretty well, but it means the application has to simulate the selection (which may or may not be integrated with the desktop selection), context (right-click) menus, etc.
What causes RSI is mostly centered around tendon and their sheath tension.
For example, if you use a straight keyboard (don't! Ergonomic all the way!) that is raised toward you as opposed to away from you, keeping your hands on that keyboard for multiple hours in a row without ever reaching for the mouse is pretty much guaranteed to give you RSI. Reaching for the mouse will actually bring relief to your tendons.
Another keyboard habit that will put a great deal of stress on your hands and wrists is leaving the Control key at the bottom left of the keyboard. Typing a control key with this configuration will bring great stress on your pinky and other tendons in your hand.
Recommendation: map Control on Caps.
I use a touchpad when possible knowing that, but I've never double checked myself. Anecdotally, I've only developed RSI in my mouse hand from gaming (same story for my friends who game as well).
NHS seems to back this as well: https://www.nhs.uk/live-well/healthy-body/tips-to-prevent-rs...
I built a trackball into my split keyboard and now I move it with my right hand and perform al clicks on my left hand side of the keyboard.
It was for me.
Most of my RSI was due to mouse usage. Moving to a thumb trackball did wonders.
> Why some devs try to avoid the mouse?
Because a keyboard is a much better peripheral to use when you're SSHing into your server. A mouse also has a much higher latency ceiling to execute most commands because it requires much more spacial awareness and brainpower to perform the task than just invoking the keybind. When you move your mouse to hover over a "send" button on an email client, your body is performing subconscious inverse kinematics to try to figure out how far to push the mouse, and when to stop. You can then only click once your mouse successfully lands in the designated area, at which point an additional 50-500ms of latency will ensue, depending on what UI framework your text editor is based off of.
The problem I see is: a lot of things that non-modal, GUI interfaces use mouse for can be better done with a keyboard.
For example, all sorts of drop-down menus and icons that you click on to launch programs. This kind of interface is inherently synchronous: the computer suggests, you pick. To me, it's way more natural to asyncronously type in what I want without having my attention hijacked by whatever suggestions my machine has (sometimes those actually make me forget what I was trying to do in the first place). I love the related metaphor ESR came up with in his Unix Coans [1].
[1]: http://www.catb.org/~esr/writings/unix-koans/gui-programmer....
Yes, especially when the suggestions change all the time, like when you go to click something and the icon is replaced by something completely different.
Here are some of mine:
M-. jump to source
M-, pop back to previous source
C-x f r Find References
C-x f i Find Implementations
C-x f t Find Type
C-x r v Rename Variable
C-x c a Code Actions
And a bunch more. I'd like to have an analogue to jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
I don't know how fast you are with the mouse, but I've watched my co-workers jump into source and they can be so slow. I believe that I can answer questions I have regarding the codebase faster than they can, I don't have to rely on my memory for trivialities.
Use IntelliJ, it's trivial to do that with `Cmd+B` (on Mac).
Better chords would be simple shortcuts for actions you do often (for example, "Go to symbol" in IDEA is \C-b).
If you use Xref UI for "Find References/Implementations/Type", M-, should work in those cases too.
There is a more general question: how to "jump forward" again, without re-invoking the previous navigation command with the exact arguments. IDEA, already mentioned in comments, has key bindings for that.
There are several third-party packages which attempt to solve it as well. I'm using this one:
https://github.com/tcw165/history
You can also add "jump back" to your other navigation commands, even if they don't use the Xref UI.
The objective and this command are fairly but not completely aligned, so it may require multiple presses of C-x C-SPC. To be clear, you only need to press C-SPC after the first invocation to repeat the command.
You don't want to iterate between the marks in the current buffer in a loop, or somehow keep track of whether each of the last three navigations changed the buffer or not (which would affect which one of the mark rings you'll have to use to go back or forward).
Using builtin commands, `C-x <left>` will switch to the previous buffer if you've jumped to another file, or `C-u C-SPC` (popping the mark) should work if you're in the same file. Not sure if this is sufficient for you, but it's a simple option to try.
C-x C-SPC will pop the global mark which, depending on what you've done in the buffer you're visiting, can pop you right back to where you started, functioning as the equivalent of M-,.
C-x b RET (C-x b with no input) should take you back to the most recently used buffer, which will usually be the buffer you started from.
Not built in: It's also fairly trivial to write some defadvice that stores your point (pre-jump) to a register, so you can jump back to the register with one key.
On any trackpad other than Apple's this becomes even more difficult. Gestures are nice but also require nuance and IME don't become part of muscle memory as quickly as keyboard use does.
Keyboard-driven workflows have no such issues. A keyboard shortcut is an immediate command to the computer to perform an action, and if that's something you do often, it will save you time and effort right away. You'll memorize it soon and forget about it since it will become part of muscle memory.
> If the challenge is to move to an arbitrary location visible on screen, then it’s logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts.
But moving "to a location on screen" is never a challenge worth using keyboard shortcuts for. If moving a cursor is your only UI option then a trackpad will be more efficient than doing the same with a keyboard of course. What you should do is use hotkeys to perform the action you would with a pointer so that you don't have to move it to begin with.
If trackpads don’t work well for you then don’t use them. I believe you, and have no interest in proving that your favored working methods are suboptimal. However, having tried the ‘keyboard first’ approach, I know that it is less efficient for me.
I do tire of the ritual haranguing of anyone who notes that they find the use of pointer devices an aid to their working efficiency.
I'm disagreeing with your assertion that "it's logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts".
I thought you were talking about moving the cursor to a general area of the screen, not within the context of a text buffer, but there I still think using the keyboard for motion is more efficient once you build up the muscle memory for it. There are plugins like vim-easymotion[1] that make this faster, but I've found plain motion bindings to be efficient enough for me.
In any case, my intention wasn't to dismiss your personal preference, so apologies if it came out like that. At the end of the day we all have a specific workflow we prefer for whatever reason, and that's fine. I just objected to the general statement that a trackpad is more efficient.
As a developer, eventually, the raw task of "writing code" is really not where I feel losing time. Tbh, most of my time developing software is reading code and thinking about what needs to be written and "doing nothing" waiting for build/test to complete.
Fast switching between tools using touchpad gestures is more important to me than being able to type faster (but I acknowledge you can do both). As a sidenote, I absolutely love macOS fullscreen mode combined with 4 fingers swap. It's such a productivity marvel that I don't understand why Windows never copied it.
But I agree that Apple's touchpad gestures are awesome and from the few times I've tried it it worked much more reliably than on any other device. Still, I haven't found a more comfortable setup than a ThinkPad keyboard + Trackpoint. The insanely short key travel on Macbooks is unbearable to me.
I think a lot of people underestimate how fast a good trackpad can be with practice. I can move the pointer to an arbitrary location on screen in less time than it typically takes me to make a key chord. However long and hard I might train on Vim (and I did use it for ~10 years!) there's a hard limit on how much time that could save me when the trackpad is already so damn fast.
The point is that using a good quality trackpad positioned below a keyboard doesn't actually require you to move your wrist much, if at all. With this set up, there is not really any cost associated with switching between the trackpad and the keyboard. Thus, there is really no benefit to using the keyboard for tasks which can also be accomplished efficiently using the trackpad (as you are not paying any significant penalty for switching between the two input methods). For example, I was able to move my mouse cursor to the 'update' button to submit this form faster than I would have been able to use the relevant keyboard shortcut.
I guess which is better for me doesn't have to be so for someone else. Mouse interfaces do have a certain simplicity to them.
Check demo animation on Saka Key's readme: https://github.com/lusakasa/saka-key
On a good trackpad you don’t actually need much visual feedback because the response is very predictable. You can make a short movement and click more quickly than you can press a couple of keys.
Saka Key looks to be both slower and more complex than navigating using a trackpad (especially once you take scrolling into account).
Also, if you haven't in a while, replace your cap. I replace mine every year or so and it makes it perform much better. You don't have to push as hard, which also reduces the drift problem.
I don't replace the cap often, but I do take it out and clean it, blow out the dust, etc. I'll give a fresh cap a try soon, thanks. It's just ridiculous this highly disruptive behavior is still a thing after all these years...
But I still prefer keyboard shortcuts, they juste feel more natural while the hands are already in "typing mode". I feel like there's a question of "waiting around". Even though I've always found the mac trackpad to be very precise, even for quick movements, you still have to aim for an icon, move the cursor to it, click, etc.
Now in the particular case of a macbook, where the windows will probably be maximized or not move around a lot, you may get some kind of muscle memory. But you still have to look around for the icon, etc. Whereas a shortcut is always the same, you press the keys and you're done, it doesn't matter where your cursor and / or window happen to be. I also prefer hidden icon toolbars, this allows me to gain some vertical space.
But, as another commenter said, some actions are easier with the mouse and wouldn't throw mine away. In my case, that's web browsing.
File management is also something that I find a lot easier with a pointing device. Also drawing diagrams, unsurprisingly!
I use the equivalent of "easy motion" aka "ace-jump" or "avy" under Emacs to move to any character on screen about 4 to 5 keypresses. Two to invoke that "jump to any character on screen" command, one to tell which character I want to jump to, then one or two depending on how many occurrences of that character there are on the screen.
I'll put it simply: my cursor is where I want it before you have even grabbed your mouse. And that is the reason why I avoid the mouse.
Same for "menus" and commands: shortcuts are faster than using the mouse. Once a list of potential candidates shows up, I use the same "select any candidate using the minimal possible amount of keypresses" command.
Unless you are typing one handed then there is inherent inefficiency in using a mouse vs. a keyboard command. Example: ctrl/cmd+c ctrl+v vs right click copy/paste.
Context: I've competed at a high level in CS/Valorant and voltaic platinum... mouse accuracy is not my issue.
Once you achieve relative fluency with using a given text editor or IDE then it is natural to gravitate towards using keyboard shortcuts.
Eventually, if you type decently fast (70wpm+, though that's slow by my standards but I'm not here to boast about the size of my epeen) many will find it frustrating moving between keyboard and mouse constantly.
In Plan 9's Acme, the mouse is your edit mode, the keyboard is your insert mode. I find I'm about as fast for most tasks in Acme as I was in Vim (after using it for years).
Now compare this with an usual "desktop session", where you may have multiple windows which aren't always in the exact same place, the cursor moves around, maybe even hidden because you've been typing, etc. Now you have to spend some extra time to 1. locate the cursor, 2. locate the button to click, 3. move the mouse over. It will probably not be slow but it clearly takes you out of the flow compared to keeping your hands where they were and knowing that whatever your shortcut you have to press will do what you expect.
What you say reminds me of synchronous-asynchronous analogy I just made in another branch of this thread.
Not needing to move my hand back and forth means not needing to make a context switch that puts a little extra stress into my workflow.
TL;DR: Moving away from the home row to arrow keys or mouse can cause wrist pains.