Firacode: Same symbol for =< and <=

[enriquin]

Hello,

After a few moments of confusion I realized that <= and =< share the same ligature.

I think there should be a difference since it's misleading. (maybe the additional line above the < when the equal sign is before?)

Thanks!

[wopian]

Duplicate of https://github.com/tonsky/FiraCode/issues/424

[tonsky]

The idea was that there’s no language where both are used, so no confusion would happen in practive. It’ll better solved when if we had profiles, as =< is much less popular than <=

[enriquin]

It would be critical if a language had both constructs, but the current implementation can hide syntax errors in languages that do not support that.

The problem is that you type =< instead of <= : It causes a syntax error, but you cannot see the error in your editor, because different "words" with different "letters" have the same "visual representation". It can be confusing.

Thanks!

[tonsky]

In theory, yes. In reality, it doesn't happen

On Sat, Aug 26, 2017, 13:47 Enrique Blanco [e-mail] wrote:

It would be critical if a language had both constructs, but the current
implementation can hide syntax errors in languages that do not support that.

The problem is that you type =< instead of <= and it causes a syntax error
you cannot see the error in your editor, because different "words" with
different "letters" have the same "visual representation".

Thanks!

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/tonsky/FiraCode/issues/479#issuecomment-325114077,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARabJLuGxmqSQMP84CshXq_BepKAIbaks5sb_fOgaJpZM4PC2zM
.

[enriquin]

Well, it happened to me like... yesterday. I lost a few minutes figuring out where the problem was but I could not see the problem until I deleted the line of code and rewrite it. I thought it was a bug/posible enhancement of the font and opened the bug, that's it. It was a way of finding errors more easily.

I respect your opinion (and your work) about it, but I think that different char combinations should have different ligatures, simply because otherwise it is misleading. It's seems unlogical that typing (and storing in the text file) different chars, those char combinations have the same visual representation when in fact are completely different things.

Just my 2c , Thanks for your work.

[dhouck]

This is another duplicate of #468, #424, and #305. It is getting almost as highly-requested as some editor issues which are definitely outside the scope of this font, and based on reactions it looks like only @tonsky and @wopian support the current version.

[ghost]

👍 from me for the change. Two different character sequences should not be represented by the same symbol in a context where the lack of ambiguity is so important.

[MadcapJake]

The problem is that different languages use different syntax to represent equal-to-or-less-than so to be fair to all camps, I think the current compromise is acceptable. Run a linter or your language's syntax checker and it will find the error and you can rectify it. I appreciate that @tonsky has chosen to follow the more inclusive path with this.

[enriquin]

Sorry, but I must disagree. I respect @tonsky decision because he is the mantainer and he decides in what things to invest his time. But (no offense) you are trying to sell a bug disguished as a feature.

I'd personally prefer to remove that ligature instead of introducing the same ligature for two char combinations. When you design fonts for readability you make the glyphs "significant" and different in a sense that (i.e.) an "O" is clearly distinguishable from a "Q" it simply saves your users from errors. You never make two letters look the same, but for aestetic reasons, that should not prevail here..

When you make a tool (and I consider this font a tool) you make it in a way so that is not only useful but makes its users less prone to errors by using it. Simply suggesting " to use a linter" is making the user add other tool that should not be necessary if the font was designed to avoid that error.

In this case the error is even more common: these are two symbols that go together a lot, that are typed using different hands, and if you accidentally swap the order have the same representation in the screen. In my case I use an IDE and the error is not immediate to see. If I run a linter/compiler/etc in a window that uses another font, I will see the error, but it creates a problem I would not have otherwise.

[tonsky]

I hear you @enriquin. If I ever figure out how to deal with profiles <= will stay in default and =< will go to specific languages (Erlang, if I remember correctly?)

[enriquin]

Thanks! Your effort is greatly appreciated.

If you ever come to Madrid the first beer is on me ;)

[premek]

Hiding typos
Java:

[nthallen]

Just to further complicate things, in VHDL, '<=' is used as an assignment operator most of the time, but depending on syntax it can also mean less than or equal to. Rendering the assignment op with a less than or equal to ligature would be wrong, but you'd need a context-sensitive render engine to figure it out.

[dhouck]

I agree that, if Fira Code gets profiles, obviously the correct thing to do will be to have =< off in the default profile and on for specific languages as @tonsky proposed.

In the meantime, popular support seems to favor keeping the =< out of the font. Please, at least make it a toggleable feature so we can add set font-feature-settings: "cv01" 1, "liga" on; in the CSS. That doesn’t require full profile support and at least helps in some cases.

[tonsky]

@dhouck, =< will go into profile. <= is less-or-equal in most languages, so it stays in the basic set

[dhouck]

Yes, that’s what I meant (edited). I’m just used to typing <= instead of =< that I wrote the wrong one, which doesn’t mean I never run into problems with the ligature.

[vladdu]

FWIW, in Erlang, =< is the comparison operator, while <= is a backwards pointing arrow...