Notes on Text Editing
github.com
github.com
> 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.
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.
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.
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?
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
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.
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.
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
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.
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
>> 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!
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?
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.
> 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
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.
As sibling mentions typing w4 will highlight and then finishing the motion with d will delete in other editors like kakoune.
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.
> 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.
"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!
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).
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
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.
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.
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)
We see this in Ardour (a DAW (audio workstation)) a lot. Quite a few other DAWs differentiate between adding a new (MIDI) note and editing an existing (MIDI) note with a modifier ("chording"). In Ardour we use modality - no modifiers.
We consider the modal model better if you're going to do multiple versions of the same sort of operation, which we believe (but do not have hard data) is the most common case.
Yeah, this also almost caused me to skip the article. Text editing is the least powerful, useful, and interesting application of these notes on general UI design.