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

Feature Request: remove break between two = when enable ligatures #347

Open
Sherlock-Holo opened this issue Aug 25, 2020 · 8 comments
Open

Comments

@Sherlock-Holo
Copy link

Description of the new feature/enhancement (with images if possible)

when enabling ligatures, the old version font will display == like
image

however, updated to the latest version, it displays like
image

please revert this change, the reason why people enable ligatures are that they don't want to see a break between ==, if someone wants to see the break, why don't they disable the ligatures?

If doesn't revert this change, please offer a subversion that there is no break between two =

@aaronbell
Copy link
Collaborator

Initially, I thought the same as you—that if you don't want ligatures, just turn them off. However, at the end of the day, legibility must trump any beautification of the code via ligatures.

As you read on the other thread, the concern is that = and == have a similar-enough length to one another that when glancing through code it can be easy to mistake one for the other. I've experienced that issue myself. So it makes sense to include a break there as a visual reinforcement of the code.

I'm open to consider adding a stylistic set that will enable you to switch to a non-broken version, though support for such functionality is dependent on the coding environment.

@Sherlock-Holo
Copy link
Author

I usually write golang and rust, both of them a==b is a bool, and a=b is a statement, it doesn't make me confused, besides the =='s length is not equal =, that reduces the possibility of confusion.

If you could add a non-broken version, I will be very grateful

@Sherlock-Holo
Copy link
Author

@aaronbell hello, is there a plan to add a non-broken version now?

@aaronbell
Copy link
Collaborator

Hi, yes. I am working on an update and would like to add the non-broken version. My difficulty is in how to do so.

The standard approach for this kind of 'alternate' glyph structure is to use 'stylistic sets'. FiraCode, for example, includes ss08 which swaps the normal, connected versions for disconnected versions of ==, ===, !=, and !==.

There's two issues to consider.

  1. In Cascadia Code, the gap is only present in one of the four of the four FiraCode ligatures. For cross-font consistency, if I'm going to offer a choice between connected and disconnected, I should introduce the other three, and they should be kept in sync.

  2. Which version is default? Code editors tend not to be the most typographically-advanced applications, and stylistic sets may not be supported (or folks may not know how to use them), so I have to decide which one (connected or disconnected) to provide to the vast majority of users. And folks tend to strongly prefer one or the other.

Ultimately, for better consistency, I'll probably need to swap back to the connected version as default, which will probably upset some folks. So I've been trying to come up with a better option. But there might not be any.

@rickdgray
Copy link

Hey @aaronbell, has there been any progress on this? This really drives me crazy personally.

@aaronbell
Copy link
Collaborator

@rickdgray thanks for the follow up! This is on the roadmap for the next feature release (the last was a big fix release), but I don’t have a specific time frame for when that will be. Sorry!

@1zizi1
Copy link

1zizi1 commented Mar 2, 2022

Ultimately, for better consistency, I'll probably need to swap back to the connected version as default, which will probably upset some folks. So I've been trying to come up with a better option. But there might not be any.

Please do not revert the default! Add it as an extra option instead.

I am short sighted person, and Cascadia is one of the few fonts that considers readability and accessibility and allows me to enjoy using ligatures.

@JAYD3V
Copy link

JAYD3V commented Mar 8, 2022

Well 1zizi1 Cascadia Code wasn't made for you. When you make a suggestion, your argument should be based on what is best for the community, and not what you enjoy the most. Personally I agree, I like the double = connected as 1. The reason Ligatures makes code more readable is because it condenses down binary operators into unary operators, and I don't have an official study from an academic source on hand, but from experience, I can tell you, the human brain can much more easily, and quickly infer the meaning of code when the amount of characters is reduced. +1 vote for no double equals. That's my argument anyways...



Personally I don't Like the Strict Equals Operator Ligature -> (===)

What I don't like is the oversized === ligature, its clunky, and its size trumps over the surrounding primitive values & function-member calls that it is often placed by. I'd argue that the strict equal ligature should be even a longer version of the assignment operator than what the equals operator is. I'm just one person though.


All Complaining Aside: Cascadia Code is Currently the Best Font Available for Programmers

I am really greatful for this font, and even more greatful that I don't have to pay 1 cent for it. The font has everything developers have been wanting in a font for years. Many fonts tried to deliver, and some offered up some good options, like Fira Code & Operator Mono. Really though, people wanted elegant cursive italics of Operator Mono, and the Ligatures from Fira Code, and Cascadia wasn't the first to deliver, but it was the first to deliver it in a way that was satisfying. The only other font thats comparable to Fira, which I often use as well, is Jet Brains Mono. Anywho, thank you sir, for your hard work.

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

No branches or pull requests

5 participants