3 ms·
> 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 d
by 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?
- Ringz 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 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.
- eviks 3y ago> 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
- Ringz 3y ago> 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 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.
- eviks 3y ago> 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
- _7tgr 3y ago> 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
- eviks 3y agoit'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.