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.

Sign up for GitHub

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

Jump to bottom

Handling of short combing arrow ligatures such as >>= should be reconsidered #435

Closed
schuelermine opened this issue Mar 22, 2021 · 16 comments · Fixed by #482
Closed

Handling of short combing arrow ligatures such as >>= should be reconsidered #435

schuelermine opened this issue Mar 22, 2021 · 16 comments · Fixed by #482

Comments

@schuelermine
Copy link

Environment

Cascadia Code version number: 2102.003
Application (with version) used to display text: konsole 20.08.2
Also occurs when using:
    Visual Studio Code 1.55.0-insider 84fe402d655e029eb1a5c04e675bf64788fa7fcf x64
    gedit - Version 3.38.0
OS platform and version: Pop!_OS 20.10
Screen resolution (i.e. 220dpi):
    1920px×1080px
    344mm×194mm (96x96dpi)

Steps to reproduce

Type >>=.

Expected behavior

A ligature appears, as with =<<.

Actual behavior

No ligature appears.

Screenshot

Screenshot from 2021-03-22 14-50-02
@aaronbell
Copy link
Collaborator

This is intentional.

=<< was implemented for the arbitrary-length arrows so you can write things like ==<<=== and so forth. However, in the case of >>= there is an operator in JavaScript that would be strange to replace with an arrow form. As a compromise, if you add another =, then it'll swap for the arrow ligature.

@schuelermine
Copy link
Author

Sure, but Haskell uses this for the bind operator, and there, it's expected to be in ligature form, especially since =<< has the same meaning, but flipped.

@aaronbell
Copy link
Collaborator

Ah, well then perhaps I should disable =<< too then :)

@mfocko
Copy link
Contributor

mfocko commented Mar 23, 2021

Ah, well then perhaps I should disable =<< too then :)

tbh if there are more suggestions for Haskell ligatures, you could turn it into stylistic set, right?

@aaronbell
Copy link
Collaborator

Certainly could.

@aaronbell aaronbell reopened this Mar 23, 2021
@aaronbell
Copy link
Collaborator

I think for now I'll disable arrow forms for all of the associated operators (=>> <<= =<< and >>=), but might add special ligatures for them in the future to give a bit of a nicer appearance—or as @mfocko recommended, add a stylistic set for Haskell use. Thanks!

@DHowett
Copy link
Member

DHowett commented Mar 31, 2021

Aw, I love the arrow forms.

@aaronbell
Copy link
Collaborator

you can still get to them via ==>> <<== ==<< and >>==! Honestly, I think it would be nice to have ligatures for these, I just don't like the inconsistency :/

@schuelermine
Copy link
Author

you can still get to them via ==>> <<== ==<< and >>==! Honestly, I think it would be nice to have ligatures for these, I just don't like the inconsistency :/

I think that line of reasoning is misguided. The thing we like about the arrow forms is that they appear in our code, not that we can type them.

@aaronbell
Copy link
Collaborator

I don't disagree that it is nice to see them in Haskell. The problem is that they cause confusion / irritation in other scenarios and users of those scenarios might prefer to not have them look like arrows as they serve other purposes.

This is why I said that it would either make sense to create non-arrow ligature forms or provide a stylistic set for Haskell-only functionality. Either way, these operators should perform the same.

@schuelermine
Copy link
Author

I agree. I just disagree with the idea that the fact that similar ligatures are still available diminishes the Haskell use case.

I really like the idea of a stylistic set for Haskell, I think that would be the best option. However, why not both? A JS-style ligature, and a Haskell-style ligature.

@aaronbell
Copy link
Collaborator

Oh, no I didn't mean to diminish the Haskell use case. More to indicate that the arrows are still available if one wants to make arrows. :)

Anyway, I'll mull over options.

@schuelermine schuelermine changed the title >>= ligature not working Handling of short combing arrow ligatures such as >>= should be reconsidered Mar 31, 2021
@schuelermine
Copy link
Author

Cool, I'm looking forward to any solutions!
I changed the title to reflect that the topic has widened.

@ExE-Boss
Copy link

I think it might be a good compromise to create a ligature for all of: >>=, =>>, <<= and =<<, that uses a narrower version of the >> and << ligatures as a base, with the = sign extending from it.

There currently isn’t any ligature for either of >>= and <<=, which is used as a bit‑shift and assign operator in C‑like languages (maybe also include the unsigned variant: >>>= and <<<=).

@chtenb chtenb mentioned this issue May 25, 2021
Open
@chtenb
Copy link

chtenb commented May 25, 2021

These ligatures don't only apply for Haskell, but also for PureScript. In fact many functional languages using operators heavily are relevant for this.

@aaronbell aaronbell mentioned this issue May 27, 2021
Merged
13 tasks
DHowett pushed a commit that referenced this issue May 28, 2021
@aaronbell
Cascadia Code Upright bugfixes (#482)
b0a6b2a 
A large set of bug fixes identified while working on the Italic, but solving
Github reported issues. 

## PR Checklist
- [x] Closes #422 - Bitcoin added
- [x] Closes #427 - FFFD glyph added
- [x] Closes #418 - top bar corrected
- [x] Closes #433 - hinting corrected to ensure alignment
- [x] Closes #435 - adds consistent ligature form for `=>>` `<<=` `=<<` and
  `>>=` (the infinite arrows still work with addition of more equals)
- [x] Closes #443 - ligature now ignores (*) scenario
- [x] Closes #454 - adds ignore to prevent equal_equal ligature from showing up
- [x] Closes #467 - Not specifically sure of the problem here, but suspect that
  it will be fixed with this - update.
- [x] Closes #477 - fixed
- [x] Closes #478 - fixed
- [x] Closes #479 - fixed
- [x] Closes #480 - fixed
- [x] Closes #481 - JetBrains enumerates fonts weird. I've modified the
  internal naming so that it will register Cascadia Code correctly. Also
  aligned postscript naming with Google's recommendation, so will show up as
  "Regular" instead of "Roman". Still works in Word!


Other Cascadia Code fixes:
- General improvement of weight balancing
- Weight of lowercase rounds reduced in the Bold weight in Cascadia Code.
- Weight of Capital stems increased in Extralight weight in Cascadia Code. 
- Tweaked weight of ogonek in ExtraLight.
- Added a localized form for ij and IJ should a user chose to use those
  codepoints and want an accented version.
- Split fraction bar at heavier weights to improve clarity of fractions.
- Adjusted standard box drawing characters to align with GDI metrics, and added
  a complete set of DWrite-specific ones that align with sTypo (using `rclt`).
- Ironed out some tiny inconsistencies in the <$ $> <$> ligatures which I'm
  sure no one will ever notice. 
- Fixed centering of braces and some hyphens.
- Fixed inconsistency between semicolon/colon and period weight in bold. Also
  fixed slight differences in hyphen-like glyphs in bold. You're as surprised
  as I am. 
- Increased weight of underscore in bold.
- Adjusted weighting of Ɫ.
- Changed design of commaaccent, commaaccentmod commaturnedabove and commaabove
  to be more distinguishable (following design of quotes).
- Increased height of βδθλ to align with the ascender height. They were too low
  before. 
- Fixed descents of various greek lowercase glyphs that were inconsistent. 
- Modified ξ weighting. 
- Felt ligated, might edit later.
- Tweaked ªºⁿʷʸᶿᶻ⁰¹²³⁴⁵⁶⁷⁸⁹ in imperceptable ways. 
- Corrected some additional interpolation bugs

I do enjoy giving Dustin presents.
@aaronbell aaronbell mentioned this issue Jun 1, 2021
Closed
@aaronbell aaronbell mentioned this issue Jun 19, 2021
Closed
@yvvt0379 yvvt0379 mentioned this issue Aug 19, 2021
Open
@aaronbell aaronbell mentioned this issue Aug 23, 2021
Closed
@2jacobtan
Copy link

2jacobtan commented Aug 13, 2022 •
edited
Loading

rip haskell users, since https://github.com/microsoft/cascadia-code/releases/tag/v2106.17

really liked the ligatures on >>= and =<<

(No discernible ligature, using the latest release https://github.com/microsoft/cascadia-code/releases/tag/v2111.01)

@bodby bodby mentioned this issue Mar 3, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Cascadia Code Upright bugfixes aaronbell/cascadia-code
7 participants
@DHowett @chtenb @ExE-Boss @mfocko @aaronbell @2jacobtan @schuelermine