Big angle brackets alternative for <> when used as delimiters

[xAlien95]

One of the downsides most users experience when using < and > as brackets is what they call "angle bracket blindness". I first faced this expression when discussing about Swift and its generic types.

In brief, "angle brackets" are shorter than the other brackets and the eye may struggle to recognize them as delimiters:

// easy
struct Optional<Wrapped> { ... }

// not so easy
struct ForEach<
  Data: RandomAccessCollection,
  ID: Hashable,
  Content: View
> { ... }

My question is: would it be possible to have full-height alternatives when used as brackets?

// better
struct Optional〈 Wrapped 〉 { ... }

// better
struct ForEach〈
  Data: RandomAccessCollection,
  ID: Hashable,
  Content: View
〉 { ... }

[tonsky]

Not when used as brackets, but can be replaced everywhere

[xAlien95]

Thank you. So a font can only be context-unaware, is that right? Font ligatures behave like combined emojis?

[RubenVerg]

The principle for ligatures is kind of the same, yes. (Your system's emoji font like Segoe UI Emoji on Windows implements ZWJ sequences with ligatures) - RubenVerg ❤️

…

________________________________ From: Stefano De Carolis ***@***.***> Sent: Thursday, March 18, 2021 2:21:21 PM To: tonsky/FiraCode ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [tonsky/FiraCode] Big angle brackets alternative for <> when used as delimiters (#1217) Thank you. So a font can only be context-unaware, is that right? Font ligatures behave like combined emojis? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftonsky%2FFiraCode%2Fdiscussions%2F1217%23discussioncomment-498229&data=04%7C01%7C%7Cc734dc16815d41ed26e308d8ea10b982%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637516704834123630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6XR6EwC2vqSKi3eO1TJL77o77qs87ipdsIiPMVWWBXU%3D&reserved=0>, or unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAMRJI3E44BQHIRCYZ7EYEHDTEH45DANCNFSM4ZLSMTBQ&data=04%7C01%7C%7Cc734dc16815d41ed26e308d8ea10b982%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637516704834123630%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=x8Lghg%2BndOXCc%2Bb7CRw5Rl9LFqjJ1La%2FoT3xnvTAhQU%3D&reserved=0>.

[xAlien95]

Thank you @RubenVerg. So, in order to obtain that behavior in, say, Visual Studio Code, I would need to develop a language server extension that adds a css class to < and > tokens when used as delimiters.

Was font-variant-alternates the right way to choose an alternative glyph? It's currently deprecated. How can I set a specific alternate via css?

[tonsky]

Yes, font-variant-alternates + styleset()/character-variant() should do the trick, but font has to support this particular replacement.