100% beam-cursor editing demo

[dpc]

For years now I've been advocating for CLI text editors to stop treating cursor as a block, and embrace cursor as a beam (aka I-shaped), just like GUI text editors.

I mentioned it before in the discussion around line-selection: #356

I just got LLM to implement it for me in Helix.

If anyone is interested here is a very short demo video: https://www.youtube.com/watch?v=qmvXbpPIA4o . The source code is at https://github.com/dpc/helix/commits/i-cursor

Such a change:

• allows to express an empty selection,
• allows to distinguish empty line and selected empty line (fixing Line-wise extend mode #356 and making Fix x behavior on empty lines #4847 unnecessary)
• makes text editing "feel" just like a GUI text editing (you might need to try it out to fully get it).

At the beginning of the video, you can see that x actually changes from an empty selection to selecting a whole line, and that's clear and intuitive.

Later you can see that secondary selections look just fine even though terminal can display only a single cursor.

The d command is altered to act like DEL key does when the selection is empty. Some other minor changes might be desireable w.r.t empty selection, but overall, this is not making text editing all that different.

[archseer]

I can't find the PR anymore but the underlying editing primitives in Helix actually support bar cursors, but we normalize them to 1-width between operations since it's hard to represent in a terminal. We were considering changing this in the future or on different frontends, e.g. webgpu

[dpc]

we normalize them to 1-width between operations since it's hard to represent in a terminal.

Oh. Interesting. Maybe that's why it was relatively easy for the LLM to get it done. I was expecting it will struggle somewhat.

since it's hard to represent in a terminal

What exactly is hard to represent?

[archseer]

Only the primary cursor can be rendered as a bar (and only in a modern terminal supporting those escape codes). We also found that most operations need at least something selected, e.g. right now you can just d to delete a character but you would need to manually extend the selection with a bar cursor

[dpc]

Only the primary cursor can be rendered as a bar (and only in a modern terminal supporting those escape codes).

As shown on the video, I think rendering the secondary selection with a block showing direction is entirely sufficient. Sure it would be ideal to just have N I-shaped cursors, but not a blocker IMO.

We also found that most operations need at least something selected, e.g. right now you can just d to delete a character but you would need to manually extend the selection with a bar cursor

Yes. Some adjustments are needed. Indeed having something selected is more handy than having selected nothing. But generally just because empty-selection can be expressed, doesn't mean it will often happen.

I immediately made d delete on empty selection. Now that I switched my system to the fork, I see that h and l should select the character they jumped over. Now I recall that in Breeze (https://github.com/dpc/breeze) where I was playing with this idea in the past, I think almost all moves just selected what they jumped over, kind of like in Kakoune.

[dpc]

Indeed having something selected is more handy than having selected nothing.

In principle one could have the exactly same behavior as right now in Helix (always forcing at least a single-character selection) except when entering empty lines, which would get an empty selection. Not sure if this is my favorite behavior, but viable for sure.

I'm planning to just play with it and tweak things until I'm satisfied.

[dpc]

After working using it for a few days... there's plenty of little problems that needs to be addressed. They all seem fixable, but I'm not sure how much it is worth to keep diverging from Helix, as I don't really want to maintain my own full fork.

[dpc]

I just kept going, and at this point I'm quite satisfied and haven't hit anything feeling wrong for a while. The biggest change was changing i to always insert wherever the cursor is. It just didn't feel good otherwise, now that the | is the core focus during editing. Plus some minor tweaks collapsing selection between changing modes, to avoid the trailing selection be confusing.