[HN Gopher] Notes on Text Editing
___________________________________________________________________
Notes on Text Editing
Author : tosh
Score : 72 points
Date : 2024-02-18 10:28 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| eviks wrote:
| 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.
| blackbear_ wrote:
| 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 wrote:
| Probably kakoune
| abound wrote:
| 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 wrote:
| Helix is another one, that tries to improve upon the kakoune
| model.
| imbnwa wrote:
| >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 wrote:
| > 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?
| gumby wrote:
| > 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!
| square_usual wrote:
| > 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?
| eviks wrote:
| 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
| jodrellblank wrote:
| If you delete one "word" you see that the "word" is gone, what
| other visual confirmation would are you desiring?
| fargle wrote:
| exactly! and if it did the wrong thing after all, just undo.
| barnabee wrote:
| 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.
| soraminazuki wrote:
| 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.
| PaulDavisThe1st wrote:
| The ideas about modality and chording are nicely laid out, but
| not unique to "text editing". They apply to any use of the
| keyboard for editing _any kind of data_.
|
| 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.
| throw10920 wrote:
| > The ideas about modality and chording are nicely laid out,
| but not unique to "text editing". They apply to any use of the
| keyboard for editing any kind of data.
|
| 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.
___________________________________________________________________
(page generated 2024-02-19 23:01 UTC)