Hacker News Reader

Comment by eviks | Hacker News Reader

With fundamental errors like this it's no wonder design improvements are rejected by the author:

> Furthermore, the effect of many motions and text objects is obvious; visual confirmation is often completely unnecessary. Deleting the current word, sentence, or parentheses block does not involve uncertainty

But it does, there is plenty of uncertainty: you can have a long sentence that wraps multiple lines, includes quotes and maybe code snippets with . inside them or just ..., so you can't easily tell where a sentence begins and where it ends.

Or even in the "simplest" case of a word selector - you can have have customizable word separators that depend on context, e.g., a valid function name is a single word even if it contains a comma in its name, so you have to keep in mind scope to guess correctly what a word motion will select

Not that big of a deal in case of a single text object, but then this gets worse with multiple cursors, so instead of doing the sometimes complicated guesswork of what objects your action would apply to you can just select, get immediate visual feedback, and proceed from there.

View on HN

> With fundamental errors like this it's no wonder design improvements are rejected by the author:

>> Furthermore, the effect of many motions and text objects is obvious; visual confirmation is often completely unnecessary. Deleting the current word, sentence, or parentheses block does not involve uncertainty

> But it does, there is plenty of uncertainty: … so you can't easily tell where a sentence begins and where it ends.

I feel the author is correct, especially considering the words I highlighted. Editors like emacs and vi began as non-visual editors (TECO and ed) used with printing terminals, so you just needed a model in your head and weren’t going to wait for a print out of the updated buffer. In fact I often shut my eyes while using emacs because I’m concentrating on what’s in my head, not what’s on the screen. I’ll open them momentarily to glance at something and hop over to where I want to edit. It helps that the primary motion command in emacs is not cursor motion but search, which is incredibly light weight and doesn’t invoke a modal popup.

But the bigger aspect is that emacs (and to a lesser extent vi) is quite definite as to what constitutes a word, token, sentence, structure etc so you don’t even have to think about it. More “modern” editors are more ad hoc, no different from modern languages that had simply one implementation rather than a spec — what’s in the implementation is by definition what the language is, just as with the old kilogram. So no wonder you find the confusion you describe: your tools are less powerful!

> More “modern” editors are more ad hoc, no different from modern languages that had simply one implementation rather than a spec — what’s in the implementation is by definition what the language is, just as with the old kilogram.

I don't understand what you mean by this. In what way is, e.g. VS Code, "more ad hoc" than vim when it comes to the definition of what a word or a line is?

I can't speak about what the person you replied to intended, but there are a few things that come to mind.

One is Unicode grapheme clusters (UAX29/the segmentation rules specifically) which browsers are expected to follow. Those rules specify things like how ctrl-right should work and, since the Unicode specifications have multiple versions and will likely have more in the future, I can understand someone who wants the program they use for text-editing to have a more stable definition of a "word" which is probably simpler to work with as it doesn't need to deal with cursor behaviour of different languages/emojis.

The second thing I thought of is to do with differences on different operating systems. Windows and macOS have slightly different text-editing behaviours which I can imagine might be annoying.

For example, if you have the text "asdf fdsa qwerty" and press ctrl-left/ctrl-right a few times, you'll see that macOS will move your text caret to start/end of the word while Windows will jump over spaces to skip to the next word.

I don't think the second point defines other editors as being "more ad hoc" and the first point is just there because VS Code uses Electron and probably inherits the browser's Unicode-compliant behaviour (I have no idea what Intellij and other IDEs do) but I would likely have an easier time remembering the simpler and more platform-consistent definition that Vim has and appreciating that about it for such a specialised tool.

The frequency doesn't negate conceptual flaw in reasoning. It also most likely stems from serious underuse of multiple cursors (another vim's flaw), which reduces the frequency of cases where it's not necessary

> quite definite as to what constitutes ... sentence, ... so you don’t even have to think about it.

My very first example doesn't depend on the strictness of definition, it's your eyes that aren't definite enough and need help with selection to show what operation will affect. Also strictness is less powerful, not more

Largely agreed with you regarding the mental model. This is similar to a push I give a lot of programmers on why autocomplete and such is not necessarily a must have feature. Definitely nice, but doesn't help with my mental model of what I'm doing at all.

Only disagreement is that emacs, oddly, is almost certainly more flexible with regards to what a word is than many other editors. With things like global-subword-mode making it so that I can transpose words in a camel case name.

I completely agree with your point, learning vim motions was quite painful (does it stop before or after this or that symbol, are dashes included, what about underscores, etc)

I remember seeing a vim clone that inverted motion and command, so that d4w becomes w4d, and the exact text included by the motion was highlighted right after pressing w4 . I thought this was a really neat idea! Unfortunately I cannot remember how this editor was called.

Probably kakoune

It's likely Kakoune, which this post has a section dedicated to. There are also other Kakoune-inspired editors that have this Vim-inverted behavior, like Helix.

Helix is another one, that tries to improve upon the kakoune model.

Leading in with a criticism like you did hurts the rest of your post. You are both free to not agree with each other. Taking the disagreement as far as to claim the other person is fundamentally wrong is rather unkind and unlikely to sway each other.

In this particular point, I think you are hitting how things don't scale up. That is, it makes sense that what would work for a small case would not work for a larger one. I expect that is the case with a lot of features.

There is also the case of trained usage versus exploratory usage. Expect that expert users need fewer feedback affordances than other users do. Further expect that you need training of some sort to become an expert. You see this even in games. And you will find far more affordances on beginner games than you will on others.

Is the assertion that there is no uncertainty a fundamental one in his argument?

I'm not clear what you are asking. (Honestly having a hard time grokking your sentence here, my apologies.)

I think you are appealing to what many would consider degenerate cases to assert that because it can have uncertainty, it always has uncertainty. Is that accurate?

If so, I don't disagree that movements can be ambiguous or hard to reason about. I'd assert the majority are not, though. To the point that in normal use, it is a fair assumption.

And again, you are free to disagree on this one. As someone that learned to type and edit without having to look at keyboard or screen, visual affordances sometimes feel off to me, personally. Doesn't mean I think they have no purpose.

I was asking whether you thought it was unkind because you disagree the part of the argument is fundamental (so being wrong there is fundamental) or you agree it's fundamenal, but just saying it out loud is unkind

> But it does, there is plenty of uncertainty: you can have a long sentence that wraps multiple lines, includes quotes and maybe code snippets with . inside them or just ..., so you can't easily tell where a sentence begins and where it ends.

Multiple lines or … doesn’t matter to vim if you want to something with a sentence since a sentence is defined as ending at a '.', '!' or '?' followed by either the end of a line, or by a space or tab. Any number of closing ')', ']', '"' and ''' characters may appear after the '.', '!' or '?' before the spaces, tabs or end of line. A paragraph and section boundary is also a sentence boundary.

One code snippet inside a sentence with ˋ. ˋ could be d2) or simply d). Feel free to add . For every . Or count them.

Word selector: try W to select that function with a , in its name. But maybe it’s better to look where your special word ends and do what you *t*+I’ll that end like ct)

... matter to vim user, not to vim, he's the uncertain party

Totally agree. I have been completely unable to learn vim beyond the basic commands and get it to stick and feel good as an editor, despite trying on and off, sometimes seriously, for two decades. Generally I think this is because of the unpredictability of actions, and the need to prepare them mentally ahead of time, with no visual feedback, then yolo the sequence of keypresses (and hope not to make a typo).

I didn't fully move away from editors like Sublime Text or VS Code when I discovered Kakoune, but I did finally find a modal editing model that makes sense to me. I work visually—the document I am working exists visually in my head, so I want that feedback (and I care about the latency in getting it).

Helix was the editor that got me to ditch all the others for a modal editor. The default keybindings are, in my view, even saner than Kakoune's. The visual feedback is better. And the fuzzy finder, space mode, LSP integration by default, etc. all make it a joy to work with pretty much out of the box.

I have no interest in spending hours/days/weeks/years on my config. I want to set a few preferences, pick a nice theme, and get to editing. Helix also delivers that better than any other editor I've tried. It's also rapid and uses next to no resources. It's not perfect, but it's developing fast and it's more usable for me than any other editor or IDE I've tried.

I tried to re-learn from Vim to Helix but failed. No sure if this is a muscle memory problem or perhaps article is right about the cons Kakoune-like approach for me. Even adapting with something like https://github.com/LGUG2Z/helix-vim did not work. So if you like Helix it probably a good thing that you did not learn the vim at the time.

>But it does, there is plenty of uncertainty: you can have a long sentence that wraps multiple lines, includes quotes and maybe code snippets with . inside them or just ..., so you can't easily tell where a sentence begins and where it ends.

If a sentence of length 'n' resides on a single line, wrapping on-screen, deleting the sentence is just 'dd'.

For more specific cases, Vim has three different visual highlighting modes that share commands one can apply to visual highlights. So in your example, I would initiate character-wise visual mode with 'v', type 'f.' to extend to the first period; then just repeat this until I found the extant period I wanted to include in the selection by pressing 'f.' as many times as necessary in the most vulgar case; or extend that selection to an obvious symbol near where I want to go, likely the one initiating an inline code block, so 't`' while in visual mode, placing the selection to the left of the opening inline code delimiter.

I've dabbled with Helix, a Kakoune-like, and it does not eliminate this problem of nested selection terminals; you're still required to trial and error since you can't immediately grok the coordinates of the nested period symbol you want to select to; both Vim and Kakoune's inputs only cover a first level.

There are popular extensions in the (neo)vim ecosystem that like EasyMotion that add ephemeral motion targets relative to your cursor position. I'm sure Kakoune has an equivalent. But there's no loss of behavior IMO between Vim and Kakoune here.

> If a sentence of length 'n' resides on a single line, wrapping on-screen, deleting the sentence is just 'dd'.

And if it's not? But this is wrong anyway, dd deletes the whole line, not the sentence

Your recipe of repeat-searching for '.' is also a downgrade fail from text object selection since multiple cursors can have sentences with different number of periods

> Vim has three different visual highlighting modes

And not a single one comparable to the criticized one since vim's visual modes always extend, and you lose selections on going back to normal

> still required to trial and error

which is much easier to do when your converging on the correct selection visually without any edit commands shifting text all around you

> But there's no loss of behavior IMO between Vim and Kakoune here.

Earlier feedback is what's lost

> EasyMotion

How does this work with multiple cursors?

> since vim's visual modes always extend

Certainly an interesting point! Maybe this'll be addressed better once nvim adds multiple cursors (it's on the roadmap).

Though I've never found this to be annoying, or felt I really wanted multiple cursors while doing something; maybe I'm inexperienced with using them. For complex/wide-ranging edits I usually record an edit action at a particular instance of what I wanna change as a macro and generalize that if necessary by composing it with more macros, instead of editing everywhere at once in one fell swoop. I think it's just a different way of going about it (which happens to work more intuitively for me).

> and you lose selections on going back to normal

FYI: gv restores the prior visual selection; I'm not sure if this is what you meant

it's indeed hard to assess what you miss if you have no personal experience as you do get accustomed to whatever the current workflow is, and in really complex/wide-ranging edits those might not even help (eg, if you have cursors outside your viewport it's not very helpful as you lose the immediate feedback that allows you to catch the errors and thus be more lax with your "list of steps", you could cycle around, but then this might not be better than cycling and reapplying your macro)

But then for less wide-ranging edits it's invaluable, and also helps in vim-golfing :) vs. having to record a macro and jump around to repeat it

Good point re. gv, didn't mean "permanently lost", but rather lost=deselected (and not requiring a restore selection step).

For example, even entering insert mode, adding a symbol, and going back to normal, retains the selection. Or entering "extend selection" mode in Helix (which is like vim's Visual mode) and exiting it also retains the selection until you move your cursor with a selection-changing operation.

>> If a sentence of length 'n' resides on a single line, wrapping on-screen, deleting the sentence is just 'dd'. > And if it's not? But this is wrong anyway, dd deletes the whole line, not the sentence

dd deletes the whole line and that’s exactly what he sad: If a sentence of length 'n' resides on a single line, wrapping on-screen, deleting the sentence is just 'dd'.

Visual mode doesn’t always extend. Try o and O.

> dd deletes the whole line and that’s exactly what he sad

And that's exactly what I've addressed: "But this is wrong anyway, dd deletes the whole line, not the sentence"

You're just repeating the same mistake. Sentences end with a period, they don't include spaces and newline on the same line after that, so deleting the whole line is simply the wrong operation even if you have 1 sentence per line, but also why should I care about such an artificially limited case when there is only 1 sentence per line???

Your O point also doesn't make sense: there is nothing to extend since the text is already selected

> And that's exactly what I've addressed: "But this is wrong anyway, dd deletes the whole line, not the sentence"

You addressed something that nobody discussed, since nobody ever sad that dd deletes sentences. The mistake is on your side and you are repeating your own mistake.

> Sentences end with a period, they don't include spaces and newline on the same line after that, so deleting the whole line is simply the wrong operation even if you have 1 sentence per line, but also why should I care about such an artificially limited case when there is only 1 sentence per line???

That's a little bit incoherent. Maybe provide an example? But I already provided: https://news.ycombinator.com/item?id=39475046 Your answer on that speaks for itself.

> Your O point also doesn't make sense: there is nothing to extend since the text is already selected

Wrong. You can extend selections. Read the manual.

Another point is, and other users already mentioned it, that you are very rude. There is no reason for you to believe that you have absorbed wisdom with spoons while everyone else just watched. Your simple black and white view "Everyone is wrong" shows that quite clearly.

> nobody ever sad that dd deletes sentences.

This can't be more obviously wrong:

> If a sentence of length 'n' resides on a single line, wrapping on-screen, deleting the sentence is just 'dd'.

No wonder with fails like this you resort to style arguments

> Wrong. You can extend selections. Read the manual.

Wrong. Moving within a selection can't extend it.

> while everyone else just watched

Unfortunately some closed their eyes so continue to know nothing

A couple thoughts to add to the conversation:

I think I prefer visual mode when I'm doing a _really_ complicated edit and need to rely on visual feedback. I think having visual feedback as the default, though, (1) causes too much visual clutter (I don't want random things to be highlighted all the time when I'm moving around) and (2) wastes keys needlessly, and causes you to have to do weird stuff as a result. For instance, if I want to select 5 words in visual mode, it's just 5w. This is not (afaict? I may be wrong) the case for the Kak/Hx editing models, which have to rely a bit more on chording (pressing shift to extend a selection in the case of Kak; I guess in Helix you could enter its visual mode and do the same?). It's also difficult to replicate Vim's repeat command.

Switching verb+object to object+verb is great, and useful-- I just don't want it to be the default. Having it be a mode seems to be a very natural solution.

Or perhaps there's a way to get visual feedback that doesn't come with these drawbacks-- but these seem inherent to the concept. Visual feedback is super useful, but it definitely doesn't come for free.

And at least IME, I usually don't need this kind of visual feedback; the edit actions I'm using in normal mode scale with the complexity of the edit. So if I'm trying to delete to some specific place, I'll probably use f/t or search as a movement or <verb>i<delim> since those are a lot more precise than trying to figure out the number of words/characters/lines to delete. And on the rare occasion that this doesn't do what I wanted, the right thing is usually just a matter of pressing . away (or, rarer, u + the thing I meant to do. I'm never really scared of doing the wrong edit, since n/vim preserves your undo history as a tree).

2) you do the same in Helix in its visual mode, so no waste. But also it's not needless, precision is the need, instant visual feedback is what serves it, showing you the target of your actions

1) have you tried it long enough (might stop bothering)? Also, maybe it could be improved by highlighting after some delay so on move you only get a highlight when you stop, not for each individual word you jump over

F/t is also a lot less precise with multiple cursors since you don't have a single unique mark, so you'd need to get there gradually (and you wouldn't count, it's also a waste with small numbers, pressing a "word forward" key 3 times is more ergonomic), and that's where seeing is better than imagining

Having tried out Kakoune multiple times, I agree with the author. Especially the part about how it eats up keys and requires more modifiers.

> With fundamental errors like this it's no wonder design improvements are rejected by the author

Except the author isn't rejecting the Kakoune model in its entirety. Nor is the argument based solely on the two sentences you quoted. As with all things, there are pros and cons. For some, the pros outweigh the cons. For others, the cons are a dealbreaker.

Also, the examples you brought up are kind of extreme and doesn't point out a "fundamental error" in the author's reasoning. The part you quoted refers to the most common cases, indicated by the use of the word "often." And some of those edge cases can easily be mitigated.

For instance,

> you can have a long sentence that wraps multiple lines

If a sentence is too long, you'd most certainly know before you try to edit it. So Vimmers would press "vas" if they require visual feedback.

> includes quotes and maybe code snippets with . inside them or just ..., so you can't easily tell where a sentence begins and where it ends.

This becomes obvious once you learn how Vim defines a sentence. It's not too hard a definition.

https://vimhelp.org/motion.txt.html#sentence

> a valid function name is a single word even if it contains a comma in its name, so you have to keep in mind scope to guess correctly what a word motion will select

Syntax highlighting should already provide a visual indicator in this case. If there's a mismatch, that's likely a bug.

You misunderstood both the author and my sentence example

"Often" refers to the fact that most of his ops are word/sentence/... , and these have no ambiguity, thus you don't need visual feedback. But he's wrong about the lack of ambiguity, his most common text objects are not clear. That's the fundamental error

Then the issue in the sentence example isn't that you can't define it or apply the definition, it's that you can't easily visually parse it due to various sentence-ending symbols not being sentence-ending, so it becomes ambiguous and requires extra effort

> And some of those edge cases can easily be mitigated.

Sure, and another easy mitigation is to switch to a more ergonomic editing model where you get it by default

> Syntax highlighting should already provide a visual indicator in this case. If there's a mismatch, that's likely a bug.

Of course there is, vim motions aren't scope based while syntax highlighting is. Unless you have a mod to make them scope based, which... introduces Uncertainty!

If you delete one “word” you see that the “word” is gone, what other visual confirmation would are you desiring?

exactly! and if it did the wrong thing after all, just undo.

Knowing what word you are about to delete.

As sibling mentions typing w4 will highlight and then finishing the motion with d will delete in other editors like kakoune.

You can do that in Vim with visual mode: v4w to highlight and then d to delete.

So then what's your argument: you don't need feedback or you do, and it's already in vim?

My main argument would be I don't understand multiple cursors unless there's a lot of identical lines which need prefixing or suffixing (and regex can do that). Vim lets you select stuff before acting on it, so "wanting to select stuff before acting on it" doesn't seem like a good reason to leave Vim. Although in practise I rarely use that.

Reply on news.ycombinator.com