More conservative ligatures?

[matthew-dean]

I find a lot of the ligature "collapsing" to be awesome, but the ligature "transforming" less so, as it seems less legible. That is, the collapse of != into the not equal ligature doesn't read the same (and in the back of my mind, I think would not be applicable to all languages, and the same with <= and >=. Perhaps there could be an alternate version of the font that did a lot of the beautiful whitespace collapsing (the -> collapsing is great), without any of the transforms to symbols that don't directly correspond to the original characters?

[j6k4m8]

+1 to this! The only reason I didn't install immediately was because there is a profound semantic difference between ≠ and !=. In fact, in this case, I even find the usage of ≠ confusing, as it takes up one em-width which, at a glance, makes it harder to recognize as not =.

On the other hand, conversion of => into prettier characters I'm all about. (I've always hated the look of the slightly misaligned => in code.)

[brianchung808]

I agree. Some of the collapsing is great, others not so much. Would be cool to be able to customize like http://input.fontbureau.com/preview/

[qntnt]

Totally agree. The biggest reason I'm not using this font is because of the difference between = == and ===. Collapsing those symbols down to different lengths for = makes certain kinds of bugs all but impossible to find.

I like the approach of this font. I just think there needs to be a little bit more thought on what helps programmers and what makes parts of their job harder.

[mholt]

Same sentiment here - I saw those != and == and I second-guessed my choice to install. The collapsed == is hard to differentiate from =.

[matthew-dean]

Yeah, I think for code, it needs to be more like "prettification" rather than completely converting to different symbols.

I don't find the == and === collapsing to be that challenging though (and kind of like it that way, since it reminds me of converting -- to an emdash), but sounds like that's just me. I did find the collapse of /> for the tag to be awkward, as is =<< and >>=. Prettying << seems fine, but removing whitespace against the = seems like too much.

I think, really, only the arrows work really well. Everything else starts to lose meaning when collapsed.

[nkoder]

Maybe ticks to marks how many equality signs are used in ligature?
I've prepared an example. Forgive me poor painting skills ;-)

[j6k4m8]

I really like this idea of tickmarks.

On Sun, May 24, 2015 at 8:33 AM, Paweł Barszcz notifications@github.com
wrote:

Maybe ticks to marks how many equality signs are used in ligature?
I've prepared an example. Forgive me poor painting skills ;-)
[image: firacode_equals_with_ticks.png]
https://camo.githubusercontent.com/6154fe13282880284609494fa84756c4fb1f13fe/687474703a2f2f692e696d6775722e636f6d2f33765239395a612e706e67

—
Reply to this email directly or view it on GitHub
#13 (comment).

[engelfrost]

In the long run, perhaps a way to pick what ligatures to use is a solution, similar to what you can do with Input: http://input.fontbureau.com/preview/

[turbohz]

@engelfrost +1
It seems impossible to create a fits all font.
There should be some kind of build step to choose some presents (per language), or customize your own.

[matthew-dean]

Maybe have a bunch of these variations and customize it via https://icomoon.io/ ?

[ahmadseleem]

I think now we see editors support one theme per Language.
So, maybe in the soon future we see one Font per language as in themes. End of the story.

[ahmadseleem]

Or the font has a set of ligatures with a unique name that can be enabled via the editor with the syntax highlighting.

[okonomiyaki3000]

👍

[tonsky]

Ok, as for =, == and ===. I made a modification so === now renders with three bars. And = and == have huge (~3×) difference in length, so you won’t mistake one for another. I also rolled back && and || replacement with ∧ and ∨.

Fira Code is mostly about tuning common symbol pairs by adjusting spacing and connecting shapes. This is fine with everybody I guess.

The only symbols I replace with new forms are <=, >= and !=. Important here is that they have universal meaning across the languages, so I’m not lying when I display ≤ instead of <=. Yes, by just looking at it, it’s not immediately clear what’s underlying structure of this ligature is.

Still, they align with Fira Code purpose: make code reading easier. It’s just so much easier to understand what’s going on by looking at ≤ or ≠ than at <= or !=. Former is immediately understandable, latter requires brain to decode: remember language conventions, make sure these two symbols actually mean single thing, etc. We’ve learned the meaning of ≤, and <= is just a poor imitation of that. You never write <= on a piece of paper, you write ≤.

It does make editing harder, but not that hard. Maybe, slightly harder. Just a little bit. I believe you can manage. It’s sure not a show-stopper. There’re just 3 of them. And I’m ok with that compromise. The benefits outweighs.

Give it a try. If after a week you’ll feel it’ve ruined your workflow, you cannot edit code, you make mistakes because of it, it’s more problems than benefits, you can always go back to what you’ve used before. Personally, I’m using Fira Code for ~6 months already. Couldn’t be happier. Never mixed == with ===, never had troubles editing <=. You may theorize about inherited problems, but in practice it all works surprisingly well.

[j6k4m8]

I've been using FC for a few days now. Love it. This change makes me love it even more.

[qntnt]

I'll definitely give it another try tomorrow. I like your reasoning behind the changes.

[larsenwork]

@tonsky It's quite easy to offer people more conservative options using opentype stylesets - let me know if you want to know more.

[tonsky]

Thanks, but truth is, I like the way FiraCode is now :)

On Sat, Jun 6, 2015 at 1:49 AM Andreas Larsen notifications@github.com
wrote:

@tonsky https://github.com/tonsky It's quite easy to offer people more
conservative options using opentype stylesets - let me know if you want to
know more.

—
Reply to this email directly or view it on GitHub
#13 (comment).

[j6k4m8]

I wonder if this is too old of an issue to revive, but the rendering of ≤ and ≥ (with the bottom 'equality' part parallel to the bottom of the carat) gets confusing on smaller font-sizes (which I've recently started using). Is there an alternate set that makes the equality part still perfectly horizontal? I find that far more intuitively readable, as the 1em-width appearance of the ≤ looks similar to <.

[tonsky]

@j6k4m8 there’s a separate issue for tracking this #117

[j6k4m8]

Sorry for the dup!

On Sun, Jun 19, 2016 at 1:21 PM Nikita Prokopov notifications@github.com
wrote:

@j6k4m8 https://github.com/j6k4m8 there’s a separate issue for tracking
this #117 #117

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#13 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAqVB88-X-ruiAmSMAPDpf9Vt3IwAfgrks5qNXqTgaJpZM4EleqZ
.