Open be5invis opened 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.
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.
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.
@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.
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.
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 .
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.
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 featureXCPP
to combine>>
only. In Haskell,>>=
should be combined, and featureXHS_
will be applied. The defaultcalt
can be restricted to "most-common" languages only. cf. tonsky/FiraCode#192, atom/atom#11846, Microsoft/vscode#6918, chrissimpkins/Hack#211, larsenwork/monoid#155