[glaukopis]

I’m always a bit disappointed that people making the case for mouse-lite workflows stop at “it makes you faster.” In many cases, this is patently false at a global scale - I’ve been using Emacs for a month and I’m certain that I’ve already spent way more hours customizing and researching than I’ll ever make back from saving a couple deciseconds every time I use a keyboard shortcut instead of a 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.

[allenu]

I agree. It's not so much "saving time" as when you are in a state of flow, you want to remove anything that slows you down from converting what's in your head to code.

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.

[fierro]

exactly. A tooling kerfuffle can really kill my vibe.

[tartoran]

To add to this, some shortcuts favorite to some users are used millions of times. Think of all that mental overhead that is saved in the long run.

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.

[Rapzid]

Yeah, in a work year writing just 400 lines of code per day will net >100k lines of code in year. That's.. A lot of new code. Greenfield, best-case kind of scenario. Keyboard shortcuts aren't going to be the secret sauce to writing a measly 2k lines of code, much less 400. Just thinking about this and discussing it probably wastes more time than a lot of those shortcuts would ever save.

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.

[pxc]

For me, tracking the mouse cursor and moving it visually is harder than moving a text cursor, since with a text cursor I can generally look at a piece of text and summon the cursor directly to that location. I have trouble seeing and distinguishing the mouse cursor a lot, and I'm much more likely to overshoot it (or move it frustratingly slowly) than a text cursor.

It just feels better for me to use. I do less squinting. :)

[gnull]

I'm not sure if Emacs qualifies as an editor for saving time. As you say yourself, Emacs people tend to play a lot with customization (and Emacs didn't seem useful with default config to me; what the hack is C-x 2?). At the same time, it doesn't add anything useful to editing itself. It's basically scriptable MS Notepad.

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.

[daptaq]

> At the same time, it doesn't add anything useful to editing itself. It's basically scriptable MS Notepad.

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.

[gnull]

Vim provides a different, more efficient modal language for talking to the editor (which Kakoune further improves). Emacs on the other hand doesn't, it just gives you some ad-hoc shortcuts. Emacs's language is no different from the one of Notepad or VS Code. It's the language of insert mode + scripted shortcuts.

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.

[gnubison]

> it just gives you some ad-hoc 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.

[karthink]

'df.' is simulated with M-z (zap-to-char). There's also a zap-up-to-char command that corresponds to 'dt.', but it's not bound to anything by default.

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.

[gnubison]

Thanks for the tip about zap-up-to-char.

> '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.

[cosmojg]

Have you tried Evil?

[daptaq]

> it just gives you some ad-hoc shortcuts

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.

[gnull]

> they are useful in practice

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).

[daptaq]

> 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.

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.

[lelanthran]

> fill-paragraph (M-q),

I use C-u-M-q. I prefer that text layout.

[Scarbutt]

Emacs and Vim are both equally efficient at text editing, I don't think you gave Emacs a fair shot. OTOH, VSCocde is frustrating to use if you are proficient at vim/emacs.

[pmontra]

> Emacs people tend to play a lot with customization

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.

[qbasic_forever]

There's a benefit to reduce stress on your hand in my experience too. Constantly switching from keyboard to mouse and back again, or even worse keyboard to trackpad, can really get aggravating after a while for some folks. I sometimes like a happy medium of VS code or other fancy editor with a VIM key mapping plugin.

[olau]

This is also why learning touch typing is helpful. It frees up mind resources. Sadly, not many people put in the effort.

[fierro]

This is such an amazing point. It's not about time saved, it's about mental continuity and the ability to stay in a state of deep work.

[skocznymroczny]

Does Vim have support for multiple cursors? It's a feature I cannot live without and I think it'd be awkward to do without a mouse.

[tharne]

Vim and neovim do not have support for multiple cursors. The vis editor, is a vim-like editor that does support multiple cursors (and also structural regular expressions, if that's your thing).