Request for extra ligature: <=

[philippefaes]

While it may not be used in Haskel, it would be nice to have a ligature for <=, akin to the ligature for =>.
This symbol is used in some other languages, notably as assignment operator in VHDL and Verilog.

[i-tu]

The symbol <= is most often used as a "less or equal" sign, ≤. An arrow ligature would be confusing for this use case. In general, I've avoided making ligatures for <= or other ambiguous symbols, since ligatures should always aid legibility, and never obscure the original characters. In this context, it's not nice that a leftwards arrow will appear in this C code: if (x<-1)

Ideally, there would be several alternative sets of ligatures that the editor could select according to language and user preferences. I'd love to work with someone on this and try to standardize code ligatures for different languages in some way. Right now, it's a compromise.

[philippefaes]

Hmm. I understand. Even in within VHDL, this is an issue. Sometimes the <= symbol is used for assignments; sometimes for less or equals. A more sophisticated editor would be able to determine the meaning and switch fonts depending on the meaning ("semantic highlighting").

Do you see a technical way of providing several options for ligatures, other than providing a separate font for each language?

[i-tu]

Good question. Perhaps someone knows more about OpenType, but It would seem that not at least using standard OpenType the way it was intended.

Hasklig uses Opentype Common/Standard ligatures at the moment. There are also Discretionary ligatures, but this results in only two sets of ligatures in an on/off-manner. Another font, Monoid, uses OpenType Contextual Alternates instead of ligatures. This leads to differing font support from Hasklig. AFAIK, contextual alternates are also on/off.

Opentype also has Stylistic Sets, but I don't know whether they could be used in conjunction with ligatures or contextual alternates to produce an alterable configuration for the font.

[colin-young]

I think it would be better to have a font-per language.

I think the right approach might to to tackle this issue from the build side. I'd love to have these ligatures in C#, but as has been pointed out, some of them have completely different meanings in different languages.

Being completely ignorant of how the font gets "built" I'm imagining there are glyph definitions that get "compiled" into a final OTF file. Is there some way that glyphs could be tagged for the languages they apply to and then produce multiple OTF outputs? Looking at the source for source-code-pro, it does indeed look as if the glyphs are separate files. Maybe some sort of extension system, e.g. A_.hs.glif, A_.cs.glif, A_fortan.glif (sorry, couldn't resist), somethingsomething_.hs.cs.glif and then pre-process to collect the relevant files before building the font. I'm sure it's a bit more complicated than that, but I think you get the general idea.

It would be a shame to have to redo ligatures that make sense to share, and it seems that attempting to select a subset of non-conflicting would just result in a less-than optimal solution for all languages.

[i-tu]

All things considered, this is a good idea. The ligature features are in features.family. With a clever shell script, this can be done, regardless of how the glyphs are represented.

(Without going into specifics, it seems SCP has (fairly) recently switched from from an ambiguous (at least to me) combination of Fontlab and UFO, to only UFO files. Hasklig is going to follow in 1.0)

Worth mentioning: larsenwork/monoid#135