Do not render ligatures under cursor (optionally?)

[max-baz]

I'm playing with font ligatures using Fira Code, it is fun to see them rendered and they convey a meaning quite clearly, however it is sometimes confusing to actually edit the rendered ligature.

For example, looking at this, the meaning is clear:

However, what's not immediately obvious is what will happen if I press Del or Backspace in this case:

In fact, in this particular case the code is:

if (a !== b) {

What I suggest to do is to not render a ligature if a cursor is currently over it, just render !==.
Then it is very obvious what Del or Backspace will do 🙂

I guess it should be relatively easy to achieve, because a ligature always takes the same number of cells as all of the the underlying "raw" characters.

I have seen people express this opinion for font creators (e.g. be5invis/Iosevka#257), where they suggest to edit the font and choose a better design. However, I think rendering "raw" characters instead of a ligature when the cursor is above the glyph is a more generic and font-agnostic solution.

I'm not sure if this requires a configuration option or should become a new behavior for everyone.

---

UPDATE: looks like I'm not the first one who thought of this (hehe), and Qterminal and Konsole already have such behavior:

[kovidgoyal]

Patches are welcome

[egmontkob]

This is "accidental" in Konsole, as it uses Qt's (or KDE's) text rendering methods for runs of identical attributes (and also stops at the cursor). See e.g. Konsole issues 361547 and 379535 for some troubles this approach causes, and it even goes worse when combined with RTL/BiDi.

(Makes me wonder what the best behavior is if cells to be ligatured don't share the exact same attributes. Should a ligature be avoided in all these cases? Kitty seems to avoid a ligature if a non-color attribute (e.g. boldness) changes, but manages to use varying colors for the ligature's fragments. E.g. a red "!" followed by yellow "==" appears as red "≡" followed by yellow "≢≡", which may hide some important semantics (e.g. the intent of the differently colored "!" in this example) but definitely looks awesome. Ideally ligature definitions in fonts could define which parts of the ligatured glyph corresponds to which codepoint and then foreground coloring could happen accordingly [background coloring would still remain an issue], but I'd guess it's not possible to define this in fonts.)

Back to the original suggestion: Should the cursor only prevent ligatures across its left edge, or across both edges? Or should it depend on the cursor's shape (i-beam vs. rectangle)?

[max-baz]

Thanks, this is interesting.

The first Konsole's issue 361547 will not be a problem in kitty due to the way how ligatures are implemented, the characters will never move because by design the "ligaturized" text takes exactly the same number of cells as the "raw" text.

Very interesting observation with colors 🙂

Should the cursor only prevent ligatures across its left edge, or across both edges? Or should it depend on the cursor's shape (i-beam vs. rectangle)?

Hm, very good question.

My first thought was that with rectangle and underline cursors I care to see the "raw characters" only when the cursor is directly over some part of the operator. The beam cursor usually indicates an insert mode where I can press Del or Backspace (so I also care about the previous and the next character comparing to my cursor's position). However, the cursor shape is not a true indicator of the "mode", for example I just opened nano, I see rectangle cursor and yet I can press Del and Backspace.

So, in summary, I think regardless of the cursor shape, the ligatures should not be rendered when the cursor is touching the operator with any of its sides.

This gif shows all of the cursor positions where I think the operator should be rendered as >= instead of the ligature:

[kovidgoyal]

It depends very much on how fonts do the ligatures.You can have fonts that convert m codepoints to n glyphs where n can be one. So in general it is not possible to detect parts of ligatures corresponding to code-points. kitty does it crudely by simply splitting the ligature into cell blocks and assuming each block corresponds to the codepoint, as you can see with differently colored codepoints. But this is, in general not true, take for example !== becoming ≢ there is no real sense in which some part of that ligature corresponds to ! and the rest to ==.

I'm actually not a fan of the cursor preventing ligatures. After all, I find symbols changing on the screen when moving the cursor distracting, and the cursor moves a lot more than it edits (in editors as opposed to the command line). Not to mention that if this is to be implemented it means you have to re-layout potentially two entire lines every time the cursor moves. That said, I wont refuse a PR to implement an option for this.

[egmontkob]

I'm not a fan of ligatures in terminal emulators at all :) (VTE bug 762832 comment 1)

[kovidgoyal]

Ligatures that span end of line are not a problem in my experience. They are simply rendered as normal characters. I haven't seen a single bug report complaining about that in kitty. This happens automatically if you do cell based rendering. You do have to jump through a lot of hoops to make harfbuzz work with cell based rendering, but once you do that, there are no major issues.

[egmontkob]

The beam cursor usually indicates an insert mode where I can press Del or Backspace

"insert mode" is a concept of very few apps (maybe vi clones only, plus the vi editing mode of readline/bash, I've heard about folks using the latter). The vast majority of apps don't have this concept. If the text underneath the cursor is editable by its nature, I expect Del and Backspace to edit it in the usual ways; if they don't, I throw that utility out of the window and hope never to have to use it again.

I've been using I-Beam cursor for years, and (apart from vim) it always gives me the expected behavior: Backspace erases to the left, Del erases from the right of the I-Beam cursor. As such, for me (and as you've probably guessed, I'm not using vim and clones) preventing a ligature only across the left edge of the cursor would be more logical. But sure for other folks, in other situations preventing ligatures at both edges of the cursor is the better. I can't see the right answer for this dilemma.

[hendrysadrak]

For example how WebStorm does it.

asd: () => {

if ( a >= b ) {

[kovidgoyal]

I'm confused, I dont see any ligatures changing in your screencaps?

[hendrysadrak]

@kovidgoyal Yeah, just an example how webstorm is handling this situation. There it doesn't change, shows ligatures as they are. First one is two letters long, second one is one letter long.

[max-baz]

The current behavior in kitty is exactly the same, and this issue describes the imperfections of such behavior. Please read the description 😉