5 ms·

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

by eviks 3y ago

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.

taeric 3y ago
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.
- eviks 3y ago
  Is the assertion that there is no uncertainty a fundamental one in his argument?
  - taeric 3y ago
    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.
    - eviks 3y ago
      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
Ringz 3y ago
> 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)
- eviks 3y ago
  ... matter to vim user, not to vim, he's the uncertain party
blackbear_ 3y ago
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.
- frabert 3y ago
  Probably kakoune
- abound 3y ago
  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.
- tomtom1337 3y ago
  Helix is another one, that tries to improve upon the kakoune model.
imbnwa 3y ago
>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.
- eviks 3y ago
  > 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?
  - 3y ago
gumby 3y ago
> 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!
- taeric 3y ago
  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.
- square_usual 3y ago
  > 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?
jodrellblank 3y ago
If you delete one “word” you see that the “word” is gone, what other visual confirmation would are you desiring?
- fargle 3y ago
  exactly! and if it did the wrong thing after all, just undo.
- wodenokoto 3y ago
  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.
  - jodrellblank 3y ago
    You can do that in Vim with visual mode: v4w to highlight and then d to delete.
    - eviks 3y ago
      So then what's your argument: you don't need feedback or you do, and it's already in vim?
      - jodrellblank 3y ago
        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.
barnabee 3y ago
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.
- orcy 3y ago
  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 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.
soraminazuki 3y ago
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 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.
- eviks 3y ago
  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!
_7tgr 3y ago
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).
- eviks 3y ago
  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

by eviks 3y ago

taeric 3y ago

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.

eviks 3y ago
Is the assertion that there is no uncertainty a fundamental one in his argument?
- taeric 3y ago
  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.
  - eviks 3y ago
    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

Ringz 3y ago

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

eviks 3y ago
... matter to vim user, not to vim, he's the uncertain party

blackbear_ 3y ago

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.

frabert 3y ago
Probably kakoune
abound 3y ago
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.
tomtom1337 3y ago
Helix is another one, that tries to improve upon the kakoune model.

imbnwa 3y ago

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

eviks 3y ago
> 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?
- 3y ago

gumby 3y ago

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

taeric 3y ago
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.
square_usual 3y ago
> 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?

jodrellblank 3y ago

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

fargle 3y ago
exactly! and if it did the wrong thing after all, just undo.
wodenokoto 3y ago
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.
- jodrellblank 3y ago
  You can do that in Vim with visual mode: v4w to highlight and then d to delete.
  - eviks 3y ago
    So then what's your argument: you don't need feedback or you do, and it's already in vim?
    - jodrellblank 3y ago
      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.

barnabee 3y ago

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.

orcy 3y ago
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 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.

soraminazuki 3y ago

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

eviks 3y ago
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!

_7tgr 3y ago

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

eviks 3y ago
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