Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Language-specific OpenType Feature Names for Programming Ligatures #192

Open
be5invis opened this issue May 26, 2016 · 7 comments
Open

Language-specific OpenType Feature Names for Programming Ligatures #192

be5invis opened this issue May 26, 2016 · 7 comments

Comments

@be5invis
Copy link

be5invis commented May 26, 2016

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. #192, atom/atom#11846, microsoft/vscode#6918, source-foundry/Hack#211, larsenwork/monoid#155

@krux02
Copy link

krux02 commented Jul 18, 2016

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
Copy link

dhouck commented Mar 20, 2017

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 microsoft/vscode#6918 (comment).

@voronoipotato
Copy link

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
Copy link

krux02 commented Mar 1, 2019

@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
Copy link

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
Copy link

dhouck commented Mar 18, 2019 via email

@voronoipotato
Copy link

voronoipotato commented Mar 19, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants