tonsky / FiraCode

Free monospaced font with programming ligatures
SIL Open Font License 1.1
77.3k stars 3.1k forks source link

Language-specific OpenType Feature Names for Programming Ligatures #192

Open be5invis opened 8 years ago

be5invis commented 8 years ago

Given the fact that in different languages, the symbol combination should be combined into a ligature are different, is it possible to provide a language-specific feature name to distinct them? For example, in C++, >>= should not be combined together, and we can assign a feature XCPP to combine >> only. In Haskell, >>= should be combined, and feature XHS_ will be applied. The default calt can be restricted to "most-common" languages only. cf. tonsky/FiraCode#192, atom/atom#11846, Microsoft/vscode#6918, chrissimpkins/Hack#211, larsenwork/monoid#155

krux02 commented 8 years ago

Yes this is a problem that should be addressed. I would like to just throw in another example: <= can either mean or . Not that I know any programming language where it means but the possibility is there.

Prolog uses =< for . if both =< and <= always expand both to people could think it doesn't matter, and therefore create confusion.

dhouck commented 7 years ago

Things like this are currently being grouped under the stylistic sets label, although this proposal is slightly different.

I agree that this should be done with custom features in addition to (or instead of) with stylistic sets as the current label suggests, mostly for consistency with other fonts (although at the moment the only font I’m aware of using this is Iosevka). This should use the standards proposed in https://github.com/Microsoft/vscode/issues/6918#issuecomment-238329621.

voronoipotato commented 5 years ago

VSCode should not dictate what individual font designers use, but rather the user should be able to turn on ligatures as needed from vscode. We already have per language configuration, then fira code could provide a vscode settings to map ligatures to languages.

krux02 commented 5 years ago

@voronoipotato this is a font, not a vscode plugin.

Since I don't think it is generally possible to configure fonts and enable certain ligatures and disable others, releasing the font multiple times with different configuration is a solution that works. Currently I have to take an old version of the font if I want my Nim ligatures back.

voronoipotato commented 5 years ago

What I meant was that the font should not follow some set of stylistic sets proposed in VSCode (which wasn't formally approved and has problems). Stylistic Sets are a way for a font to have ligatures that only appear some of the time. It's similar to what you're talking about releasing the font multiple times. FiraCode should define StylisticSets according to the FiraCode's needs and not VSCode's after all there are users who use emacs and vim etc. VSCode should support stylistic sets universally, instead of looking for a small set of "keyword" stylistic sets.

dhouck commented 5 years ago

The proposal in the VSCode bug is an attempt at proposing a standard. I agree that a big comment thread on GitHub isn't the best place to do that, but there should be some standard and I doubt OpenType will want to standardize this themselves because I think they’re more concerned with communication languages.

Regardless of anything else, there is value in matching Iosevka’s feature names in order to make changing fonts easier. Sure, I could rewrite a config file to change one set of feature names to another, but that's a lot of work when trying out a new font is already more of a pain than it should be.

On Mon, Mar 18, 2019, 09:40 Alan Ball notifications@github.com wrote:

What I meant was that the font should not follow some set of stylistic sets proposed in VSCode (which wasn't formally approved and has problems). Stylistic Sets https://glyphsapp.com/tutorials/stylistic-sets are a way for a font to have ligatures that only appear some of the time. It's similar to what you're talking about releasing the font multiple times. FiraCode should define StylisticSets according to the FiraCode's needs and not VSCode's after all there are users who use emacs and vim etc. VSCode should support stylistic sets universally, instead of looking for a small set of "keyword" stylistic sets.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/tonsky/FiraCode/issues/192#issuecomment-473996576, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgCfRHosAqEscUtuAHmdul_TDOpMh2Sks5vX8FigaJpZM4Infu2 .

voronoipotato commented 5 years ago

Oh I'm just saying that VSCode should support any and all stylistic sets and not just a subset of them. If you want to use the labels described in the issue that's fine by me :). I just want to be able to do things like use a cursive stylistic set on comments, etc.