Ligature for "===>" buggy

[Midar]

Right now, ===> gets rendered as === ligature and > - which looks really strange. Could either the === ligature be disabled if followed by an >, or a ligature for ===> be added?

[qgates]

This doesn't appear as a ligature in Fira or Hasklig either. What language is this symbol used in?

[Midar]

It's a common sequence in terminal apps. I don't think there needs to be a ligature for ===>, but it would make sense to disable the === ligature when it's followed by a >

[philippnurullin]

@Midar Can you send the screenshots with its usage, & explain more context. When it's used & for what propose.

[qgates]

Don't want to speak for @Midar but when using ===> it looks strange when the === part is converted into its ligature. Midar's suggestion of disabling the ligature when followed by > would definitely be better, alternatively a longer version of ==> ligature might work too.

FWIW in case you missed above, Fira Code and Hasklig seem to have the same issue.

[auduchinok]

Sometimes this sequence is used as a progress indication, adding more = as it's progressing.
Here're some examples found online:

https://www.mathworks.com/matlabcentral/mlc-downloads/downloads/submissions/30297/versions/2/screenshot.PNG

https://www.tecmint.com/wp-content/uploads/2015/10/pv-command-examples.png

Here's another progress lib example, though it uses - instead of =:
https://github.com/eichf/progress_bar

[qgates]

Yes, and since ===> isn't a meaningful symbol in itself I would probably lean towards disabling the ligature in cases where its prepended with < or appended with >. I don't think there are any edge-cases where this wouldn't work.

The alternative is to change the === ligature to be a longer version of the == ligature, which would fit these use-cases better than the current three line version. But that's more work, and I'm not sure everyone would agree 😉

[andrebrait]

Personally, I wouldn't like === to be just a longer ==. The length along wouldn't make for a good way to distinguish the two when reading code.

[Midar]

@qgates No, that's exactly what I meant :).

Here's a screenshot of how it looks (first line) and how it should look (second line):

Alternatively, of course, there could be a ligature like for ==> - I guess ===> is not that uncommon, and it would look nicer if an app uses several levels, e.g.:

===> Main action that is being done
==> Task of that action
=> Some subtask

Which, of course, would look inconsistent without a ligature for ===>. But then the question is where to draw the line. ====> maybe? I don't think I've ever seen more than that in these cases.

Of course, the least effort and completely sufficient is to just disable the ligature for === if it's followed by anything other than space, alphanumeric or $, as then it's very very unlikely to be used for a comparison.

[thewilkybarkid]

Just seen a progress bar in a log file showing ligatures sometimes being used:

[qgates]

As ligatures are meant to provide meaningful symbol replacements, if possible they should probably be disabled in these edge-cases since there is no meaningful ===> symbol, ie. === with < or > at either end.

Speaking more generally, I'd be curious to know how other ligature fonts like Fira Code or Haskell deal with situations like @thewilkybarkid posts above: I suspect it will be much the same. When ligature fonts are used in a text editor, for given file/syntaxes many modern editors allow ligatures to be enabled or disabled either entirely or for given lexer scopes. This could be a viable workaround for (eg) viewing logs in an editor.

Just an opinion, but JBM is designed primarily as a coding font where ligatures are most useful. Perhaps in time a version of the font without ligatures will be available that would better suit general terminal / console use.

[philippnurullin]

I think disabling the ===> sequence is a good move. I agree with @qgates that this symbol doesn't have any logic behind it so it will only create noise.

The problem in loading sequence like [==> can be treated by adding the exclusion if it have [ in it.

@Midar

===> Main action that is being done
==> Task of that action
=> Some subtask

Is this a common practice? Seeing it for the first time. What language is this?

Fira Code

Hasklig

[Midar]

It's quite common for any type of grouped output, or progress output indeed. A similar problem exists with ***, where for two * it's normal as it is for four, but for 3 one is a little higher.

I think it's not worth adding a ligature for ===>, but to just disable the === ligature if anything other than [0-9a-zA-Z\s$] is followed, because I don't think having the === ligature followed by an > is something that would ever be wanted.

[philippnurullin]

This changes won't affect the === ligature. Only the ===> [=> [-> sequences is treated.

[trygveaa]

Seems like the -- and --- ligatures are still used in [--> and [--->. I guess those should be excluded as well?

[philippnurullin]

Yes, they are. Will remove them in the next update. Thanks!