Add ligatures

[larsenwork]

Like e.g. https://github.com/tonsky/FiraCode

I'm still trying to figure out how best to solve it technically though

[plgruener]

the !! is a bash alias for previous command, it stands alone. And there also seems to be others with ! and a following char, like !? or `!#' – but I doubt they're often used, so it's not urgent. (Although sometimes I comment things with "what's that for?!" ;) )

Examples for the others:

def name = person?.name (assign name only if person is not null) def fun = str.&toUpperCase (used to store a method pointer) def makes = cars*.make (apply make to all elements of the cars-collection) def range = 0..<5 numbers 0 to 5 exclusively (in contrast to 0..5 which are 0 to 5 inclusively)

Most of them look ok without ligatures, except for ..<

[mikebronner]

There are also tempting syntaxes that use {!! some command here !!} and {{ some command here }} and {{{ some command here }}}. Would these be suited for ligatures as well?

[larsenwork]

@plgruener

Diacritics are almost done

@mikebronner I think they could be improved...stay tuned :smile:

[plgruener]

Hmm, the same would apply for any amount of opening/closing brackets. I mean ()))) is also not uncommon, as well as ({}) or something. I understand your approach of defining new ligatures is to assign a special sequence of characters to a new one. This wouldn't be suited for "any amount of brackets", would it?

[plgruener]

@larsenwork subtle differences, but looks good to me. Did you alter the position of the ..< ?

[plgruener]

I was looking at Haskell-ligatures (not using it, but these folks seem to like ligatures), and I think the following need fixing: =:= center colon between the equalsigns, :: squeeze them a bit together, <== ==> should render to long double arrows like =>, >>= =<< are broken by the existing <= ligatures

evtl also <<< , >>> , -< , >- , -<< , >>-

[larsenwork]

@plgruener any-amount: ligatures are only really suited for 2-3(-4) characters. I'm currently building an update that fixes e.g. &&& (currently broken) ..< problem was ".." got recognised first and then left the "<" hanging. =:= can be centred although the : will not be as sharp. Seems like a good tradeoff though. <== ==> >>= =<< should be an easy fix

[larsenwork]

[larsenwork]

@Fequois I've done the same as with hyphens (make them narrower when more than one) so it's easier to see how many underscores there are

[larsenwork]

compared to

[larsenwork]

nah...can be better, two sec...

[Fequois]

Hahaha, love your workflow. <3

waits for the next set of images

[larsenwork]

[plgruener]

yep, looks clearer now. so this is for any number of underscores (>1) ?

[larsenwork]

@plgruener yep but n=2 is a special case

[Fequois]

@larsenwork I like it, too. Very nice.

[plgruener]

hmm, same maybe for ~~ ?

[larsenwork]

Thanks, up next is perfect shrug ¯\_(ツ)_/¯ ligature...just because...

[larsenwork]

@plgruener I think the ~ will get too condensed + it looks ok now because it's not "end-to-end" so it's easier to tell them apart if there are many

[larsenwork]

https://twitter.com/larsenwork/status/626424006174973952

[plgruener]

Yeah, priorities! :+1:

@ ~~ I just wanted to throw in the idea.

[cabralRodrigo]

I don't know is this is the right issue but I'm using monoid to develop typescript and the ligatures for the operator !== seems a little odd.

I don't know if is even possible to do something about it, but would be really nice if this could change :)

BTW, awesome font to develop :)

[larsenwork]

It's how it's designed "notequal + type" "≠="

Any other ideas as to how it could/should look?

[cabralRodrigo]

I really don't have any ideas, maybe something like this:

But I can see that this can be a little confusing with the current !=.

And, if this is this way by design I can get used to it.

[larsenwork]

@cabralRodrigo yep, I deliberately didn't do like e.g. fira mono because I don't want there to be any confusion between !== and !=

[cabralRodrigo]

@larsenwork Thanks for your time anyway :)

[luben]

In gEdit ">==>" is rendered like a " ==>" (with leading space) : not that I know of programming language that uses it.

[luben]

Also "foo <- bar" is rendered as "foo - bar"

[luben]

Correttion on the previous comment, regarding "foo <- bar". It renders incorrectly with the Retina face but renders correctly with the Regular one. ">==>" renders incorrecly in both of them

[larsenwork]

@luben cheers, "<-" is fixed in next update Because of my approach (using contextual alternates and not conventional ligatures (read why in the medium articles)) random strings of "<", "=" and ">" will render with errors...not sure how to fix this. Other than to include specific solutions for those combinations used by programming languages (e.g. <==>)

[blixt]

@larsenwork The !== ligature is very confusing to me and was the one thing that stood out to me as something that makes code less readable. To me, and I'm sure many others, it reads pretty much like a broken form of regular "not equals" (because it just has two regular equal signs).

Semantically, identity equals is a three line equals sign (≡) and with a strikethrough it would be equivalent to !==. I would do just like Fira Code does it, which is immediately clear to me:

If keeping the current one is something you feel strongly about, could the more semantically correct version perhaps be available as an optional font feature?

[in-in]

I agree with @blixt. The first time I saw that !== ligature, I thought it is broken. It is look weird in such perfect font. Double m also confusing me.

[larsenwork]

@blixt a good idea, I will look into it this christmas :+1:

[larsenwork]

@blixt @in-in I have a problem with the "==" ligature though...it's aesthetically doing what e.g. Fira Code does and merge the two equal signs but then it's only by length that you can distinguish it from a single equal sign...not sure what's the optimal solution

[larsenwork]

[in-in]

You're right, it looks a bit alike. I tried your sample in editor (Fira Code). You can see different height between lines.

[marnen]

@larsenwork:

I'm trying to keep this a strictly monospaced font so hack job like combining two characters in to one wider character isn't kosher. Instead I'm thinking about using contextual substitution like this

A belated note of thanks for this idea. That's how I did it in https://github.com/marnen/borg-sans-mono, and I think your work was where I found the technique.

[larsenwork]

@marnen cheers, I've recently changed my opinion about this a bit though so I think I'll make more ligatures that span multiple letters 🤷‍♂️ 😉

[marnen]

@larsenwork Does that mean that you're now doing something like this?

sub a_b.left_half b' by a_b.right_half
sub a' b by a_b.left_half

(If you're curious, here's what I did: https://github.com/marnen/borg-sans-mono/blob/master/BorgSansMono.fea.)

[larsenwork]

@marnen essentially yeah, because more and more editors and terminals support this kind of ligatures now (didn't do that when I created Monoid)

Thanks for the link btw 👍

[marnen]

Right. I don't especially like the idea of the left and right halves being separate glyphs in the font, so I probably wouldn't do it that way unless there were some overwhelming advantage.

[larsenwork]

@marnen they actually aren't in Monoid either — if it's a ligature that spans three letters then the first two are substituted to empty letters and the third one has the entire ligature. But it's complicated to maintain so normal ligatures is obviously they way to go now that editors support it.

[marnen]

Does that work in a monospaced font, though? I wouldn't expect it to, at least not with proper caret positioning, hence the space trick that I use in Borg Sans.

[larsenwork]

that's how all my "ligatures" have been created so far but it's annoying having to substitute with 3 characters instead of just one.