zlacker

Commit Mono font does something similar and calls it “Smart kerning”. Visit https://commitmono.com/ and click on the “04 Intelligent” tab for details.

In practice this is unusable. Because the width of the letters now depends on the succeeding character, the text jumps as you write it. Super annoying.

Cool for reading. Awful for writing.

>>nvarto+(OP)
Exactly my experience as well.

>>nvarto+(OP)
It doesn't in this font? Possibly because of what they talk about where it optimistically gives as much space as possible to succeeding glyphs. You can try it on the page; the code sample boxes are editable. I see no jumping when I type "calming", their example word.

[append] Oh, I do see some jumping when I type "optimized". Honestly, it doesn't seem very jarring to me; the jumping is always right where the edit point is so the added or removed letter causes a much bigger jump.

>>nvarto+(OP)
If this gets popular, I could see a text editor that lets you use a non-healing version of the font for any text that has been written in the viewport and then swaps it out as soon as you no longer looks at that block of text – or straight up uses a different font for my modifications compared to the committed code.

But even without anything like that, if it’s good for reading I like to use different fonts when reviewing and writing code to help with the context-switch, so I think this could be useful to me. And I guess people in regions where a single keystroke isn’t always a single character such as Korea, China, Japan and the arab world might be used to the jarring effect already?

>>sakjur+QX
> I could see a text editor that lets you use a non-healing version of the font for any text that has been written in the viewport and then swaps it out as soon as you no longer looks at that block of text

The text editor widget on their page is a bunch of "line" divs with individual terms being inside spans. If you add an inline style of

  font-feature-settings: "calt" off;

or, more completely,

  font-feature-settings: "calt" off,"dlig" var(--ligatures,1),"ss01" var(--ligatures,1),"ss02" var(--ligatures,1),"ss03" var(--ligatures,1),"ss04" var(--ligatures,1),"ss05" var(--ligatures,1),"ss06" var(--ligatures,1),"ss07" var(--ligatures,1),"ss08" var(--ligatures,1);

to a single line div or a single term span, it won't do the healing. If one of the CSS pseudo selectors worked for these kinds of elements (I see there are a lot that apply to forms, but.. maybe :active / :active-within would work for editable spans?), you could have healing automatically apply to terms when they 'blur' / when they're no longer active.

>>sakjur+QX
If it's good for reading, it's especially good for Github itself, which is a largely read-only interface for code.

>>nvarto+(OP)
Unrelated, but why is it that Font marketing pages specifically always have such cool-looking demoes? I love the navigation on that site, I might steal that for my own site

>>sensan+bp1
Probably because if you care about typography, you care about design and you crafted that demo page with passion, instead of picking a free template with 3 columns adorned by free icons of rockets, gears and brains.

>>nvarto+(OP)
Could the “jump” problem be improved with a subtle transition (200ms, 1s, etc) from one state to the other?

If the editor “repaints” commit mono on the letter-pair boundary, I could see that being a very jumpy UX — ie: the letter I just typed is moving by a few pixels. But if that repaint happens on the word boundary it might be less noticeable?

In either case, a transition could be helpful for commit mono and/or Monaspace. (But agreed with above comments that Monaspace is more subtle because it spreads the spacing over the entire word, so maybe the transition is not actually percievable or worth it). :)