Hacker News Reader

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.

exactly. A tooling kerfuffle can really kill my vibe.

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.

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.

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

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.

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

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.

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

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

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.

Have you tried Evil?

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

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

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

M-spc just inserted a space for me. Do I need some package for it to work? What does your sequence of commands mean in English?

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.

My bad, meant C-SPC.

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

I see the point. The Emacs way can also be seen as object-verb, it's just that object is given via selection. I don't have any objections to what you said, maybe I was wrong about Vim/Emacs difference.

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.

> But. Kakoune is still something bigger for me

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

> fill-paragraph (M-q),

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

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.

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

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.

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

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.

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.

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