VHDL: <= is assignment (not less-than)

[larshb]

The <= operator is essential in VHDL, but it is an assignment operator and should be the mirror image of =>. Is there any way to replace the ligature for VHDL specifically (by IDE or otherwise) or do I need a separate font altogether?

[tonsky]

Not yet, but hopefully I’ll have something soon

[adb-luna]

(This is all with Fira Code 6.2.)

It looks as though the cv20 will provide a <= for VHDL rather than ≤ based on this graphic. I am trying to use the pyftfeatfreeze program to generate a new font file with this cv20 as default. It works for ss01 to change the shape of r. Other ss and cv work as well. But when I try cv20 or ss02, no remapping is done.

I'm just wondering if some cv or ss glyph names are incorrect in cv20 and ss02.

Here are some details.

When I try ss02 which tries to modify greater_equal and less_equal, I get remap warnings and no remap occurs. See the lines with WARNING below.

$ pyftfeatfreeze -i -v -n -f 'ss02' -R 'Fira/FiraTest' FiraCode-VF.woff FiraTestCode-VF.otf
INFO: [RemapByOTL] Running with options: Namespace(features='ss02', info=True, inpath='FiraCode-VF.woff', lang=None, names=True, outpath='FiraTestCode-VF.otf', replacenames='Fira/FiraTest', report=False, script=None, suffix=False, usesuffix='', verbose=True, zapnames=False)
INFO: [openFont] Opened font: FiraCode-VF.woff
INFO: [filterFeatureIndex] FeatureIndex: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67]
INFO: [filterLookupList] Features to apply: ['ss02']
INFO: [filterLookupList] Lookups: [318]
WARNING: [applySubstitutions] Cannot remap 'greater_equal.liga' -> 'greater_equal.ss02' because neither has a Unicode value assigned in any of the cmap tables.
WARNING: [applySubstitutions] Cannot remap 'less_equal.liga' -> 'less_equal.ss02' because neither has a Unicode value assigned in any of the cmap tables.

INFO: [renameFont] New family name: 'FiraTest Code'
INFO: [renameFont] New full name: 'FiraTest Code Light'
INFO: [renameFont] New PostScript name: 'FiraTestCode-Light'
INFO: [saveFont] Saved font: FiraTestCode-VF.otf
INFO: Finished processing.

If I try cv20 directly, nothing happens. No warnings at all, but no remaps either.

$ pyftfeatfreeze -i -v -n -f 'cv20' -R 'Fira/FiraTest' FiraCode-VF.woff FiraTestCode-VF.otf
INFO: [RemapByOTL] Running with options: Namespace(features='cv20', info=True, inpath='FiraCode-VF.woff', lang=None, names=True, outpath='FiraTestCode-VF.otf', replacenames='Fira/FiraTest', report=False, script=None, suffix=False, usesuffix='', verbose=True, zapnames=False)
INFO: [openFont] Opened font: FiraCode-VF.woff
INFO: [filterFeatureIndex] FeatureIndex: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67]
INFO: [filterLookupList] Features to apply: ['cv20']
INFO: [filterLookupList] Lookups: [380]

INFO: [renameFont] New family name: 'FiraTest Code'
INFO: [renameFont] New full name: 'FiraTest Code Light'
INFO: [renameFont] New PostScript name: 'FiraTestCode-Light'
INFO: [saveFont] Saved font: FiraTestCode-VF.otf
INFO: Finished processing.

This is what happens when a remap successfully occurs (for ss01). It shows the successful remap, and I do see the alternate r in the resulting font.

$ pyftfeatfreeze -i -v -n -f 'ss01' -R 'Fira/FiraTest' FiraCode-VF.woff FiraTestCode-VF.otf
INFO: [RemapByOTL] Running with options: Namespace(features='ss01', info=True, inpath='FiraCode-VF.woff', lang=None, names=True, outpath='FiraTestCode-VF.otf', replacenames='Fira/FiraTest', report=False, script=None, suffix=False, usesuffix='', verbose=True, zapnames=False)
INFO: [openFont] Opened font: FiraCode-VF.woff
INFO: [filterFeatureIndex] FeatureIndex: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67]
INFO: [filterLookupList] Features to apply: ['ss01']
INFO: [filterLookupList] Lookups: [317]
INFO: [applySubstitutions] Remap: 'r' -> 'r.ss01'
r.ss01
INFO: [renameFont] New family name: 'FiraTest Code'
INFO: [renameFont] New full name: 'FiraTest Code Light'
INFO: [renameFont] New PostScript name: 'FiraTestCode-Light'
INFO: [saveFont] Saved font: FiraTestCode-VF.otf
INFO: Finished processing.

[adb-luna]

FWIW, I decided to dig a little bit and figure out how to specify stylistic alternates and character alternates in GVim. It's a hack, but it works. I specify the font like this (everything after the + is passed as a pango font feature): :set guifont=Fira\ Code\ Regular\ 13+cv20\\,cv12\\,ss10\\,cv24\\,ss01. Note also that guiligatures should be empty. I'm not sure why they opted for a table look-up in the current GVim implementation when pango itself can take care of them.

[larshb]

I'm primarily using VS Code. I can enable cv20 to get what I want (arrow left) by adding the following to my

settings.json:

    "[vhdl]": {
        "editor.fontLigatures": "'ss01', 'ss03', 'ss04', 'ss05', 'ss06', 'ss07', 'ss08', 'ss09', 'zero', 'onum', 'cv20'"
    }

I now have the opposite problem: no arrow right. None of the stylistic sets or variations in the example from @adb-luna seem to do the trick. Anyone by chance know where to find the arrow-right style/variation?