Add Triple Equals Ligature

[DomBlack]

Would it be possible to add the triple equals operators;

Characters	Currently	Ideal
===
=!=
!==

[fabrizioschiavi]

No problem if other PragmataPro users agrees

[dhouck]

I do not use PragmataPro (I follow the repository because I keep thinking I might), but I use a different programming ligatures font, FiraCode. One of the most requested features over there is changing the triple equals ligature from what is in the Ideal column to something else.

I don’t have a problem with the FiraCode triple equals myself, but the two major complaints are that it is too bulky (it is three characters long and taller than a lot of others) and that it is asymmetric at some font sizes (because there is no way to make it look good on a pixel grid except at very large font sizes or DPI).

Maybe you have a way to solve these problems, but you should probably be aware of them.

[DomBlack]

My main annoyance was more the space which occurs in =!= between the first = and the !=

If that was removed, that would resolve my main issue, and yes I used FiraCode as an example instead of drawing it up myself.

[fabrizioschiavi]

Don’t worry I’ll add this new ligature in Pragmata Pro style 😉

[carlosvigil]

I like the !== currently, as it makes more logical sense, and agree with === being combined like in Fira

[Porges]

I don't really like the 3-layer equals. I like the way Pragmata Pro does them currently, where you can still tell what the 'real' representation of the operator is. (e.g. consider the difference between the -> ligature and the ⇾ arrow in Pragmata Pro – the former has a very light vertical bar on the arrowhead.)

[rvlzzr]

I would prefer a triple-layer === and !== over the current ligatures. It's easier to distinguish == vs === and != vs !== with the extra layer.

[CodeMonkeyMike]

I prefer the triple-layer equals over what is there currently, it adds an extra level of understanding to Javascript and PHP code equality (where both == and === are valid and do equality but at a different specificity)

[fabrizioschiavi]

For me three horizontal bars means equivalence. Please explain me why === must be interpreted as an equivalence 😕

[DomBlack]

I think the main problem is visually being able to clearly separate the two types of equal as they have enough different meaning that bugs could be introduced easily.

Sometimes you want the == version, most of the time you want ===, but it’s really easy to mistake them during a review if the font isn’t clear

1 == 1 // true
1 == “1” // true; they have the same value, even though one is an integer and the other a string
1 == true // true; when casted an a int, true becomes 1
1 === 1 // true; they have the same value and type

10 == “abc” // false 
10 === “10” // false; same value but different data types

[dmikov]

@fabrizioschiavi Because it is equivalence. This statement in js variable1 === variable2 means strict equality vs == meaning loose equality. It would be super nice if it was doing it like Fira.

[ghost]

@dmikov in mathematics (higher algebra and category theory for instance), "strict equality" is not the same thing as equivalence. Equivalence is the weaker notion.

Personally, I don't think it's a good idea to have this ligature for the reasons already stated above. I think it is more confusing than helpful.

In unicode, we have the symbols = (EQUALS SIGN), ≡ (IDENTICAL TO), and ≣ (STRICTLY EQUIVALENT TO). Sometimes ≡ is also used for bidirectional implication for propositions which is again slightly different. In mathematics, what "identical to" actually means is very complicated and subject to a lot of current research and debate (see higher category theory and homotopy theory). Having a symbol which looks like ≡ but is slightly longer and has some other connotation just seems weird.

[dmikov]

@freebroccolo I don't understand what your first point has to do with anything, it should be obvious to anybody that depending on the field of study words differ, which has nothing to do with triple equal sign visual appearance. Reasons already stated above was about length/bulky not confusion, everybody above find === vs == more confusing. Why would having longer symbol be confusing, already people code with == and === which is just longer, and != and !== ligatures only differentiate in it's length and it doesn't seem to confuse anybody. Many ligature fonsts like monoid or fira implement it like that.

[ghost]

I don't understand what your first point has to do with anything

I will try to clarify.

Fabrizio said the following:

For me three horizontal bars means equivalence. Please explain me why === must be interpreted as an equivalence 😕

I think it's clear from the context that he was referring to "equivalence" in the technical sense of equivalence relation. This sense of "equivalence" does in fact mean the same thing in both computer science and mathematics. In this sense, an equivalence relation is usually a coarser notion than "strict" equality except in degenerate cases in which there is no interesting structure that is respected by the relation.

Then, you say the following:

Because it is equivalence. This statement in js variable1 === variable2 means strict equality vs == meaning loose equality.

But in the technical sense I just explained, === is not the equivalence relation that one would normally be thinking of in this scenario. As you say, it's just the "strict" equality. If anything, == is the coarser relation, although even that is not really a proper equivalence…

Perhaps none of this is interesting and you don't care about equivalence anyway, or you only care about it in the colloquial sense. That's fine, but Fabrizio did ask the question and I think it's worth pointing out that === is not equivalence in the sense he asked about (as I understood him).

I don't think it's a good ligature because it doesn't look like the original string and it does look like another symbol which usually has a different connotation. I also don't think Pragmata Pro should automatically just do it simply because some other fonts do it.

But honestly I don't feel that strongly about it either way.

[wismill]

Please note that === is also used in other contexts, such as definition of headers in reStructuredText. The meaning of === varies from one programming language to another. I think the current version is ok.

[CodeMonkeyMike]

@wismill Triple equals sign is not an operator in reStructuredText, its "n" number of equals sign. If its an issue for you then just make sure your headers are 4 equals signs long because it will break the ligature back into normal equals signs. @freebroccolo I was under the impression that the ligatures were for programming not math. There are things like Mathjax for that. Now if you take the top 10 programming languages by use, there is no detrimental effect for the triple equals.

I should note, the bigger issue for me is the !== operator which is very hard to tell between the != harder then just having no ligature at all. I found myself yesterday having to go cursor over the ligature to make sure it was != not !==

[ghost]

@freebroccolo I was under the impression that the ligatures were for programming not math. There are things like Mathjax for that. Now if you take the top 10 programming languages by use, there is no detrimental effect for the triple equals.

Many people use this font for computer-aided theorem proving (Agda, Coq, etc.) which is both programming and mathematics. Example:

Pragmata Pro is the only font of its kind that has full coverage of the unicode math range. Mathjax and LaTeX are only useful for typesetting; they aren't a substitute when you need to be able to use the proper symbols directly in the code.

Regarding the ligatures vs actual unicode glyphs, each of the current "math-like" ligatures bears a close resemblance to the glyphs that comprise it. Not only that, but they look distinct from the similar unicode glyphs. Compare the ligature for -> to →.

Using the "ideal" column for === would seem break that pattern and I think it looks too close to ≡.

[wismill]

@CodeMonkeyMike I am not going to modify all my files, just because a ligature breaks an important principle that @freebroccolo mentioned: the ligatures should bear a close resemblance to the glyphs that comprise it.

[dmikov]

@wismill You don't have to modify your files. Even if you decided long ago to make YOUR headers = x 3 only. Nothing breaks if you have ligature in source. Your render is unaffected. Regarding "important principle", I guess we disagree -- for programmers showing intent and distinction is way more important then close resemblance, if it was we didn't need ligatures at all, because nothing resembles closer then the original characters.

[DeLaGuardo]

Just as an example of how such a replacement might look right now using current ligatures for the triple equations.

[CodeMonkeyMike]

Is it possible we could just use font patching to satisfy both camps? Lets say the default is what we have now and for those who want alternative === can use a font patcher.

[wismill]

@dmikov First it is not about my headers, it is about the syntax of reStructuredText. It uses sequences of "=", "-", etc. to underline titles. Please read the documentation before making false statements. Please do not generalize about what programmers want; they (including me) have various needs because of different languages and paradigms. And diversity is fine.

The proposal of the new ligatures will break the readability of my file as much as the files of anyone else. And it is also true for tables in Markdown, and also have an impact on the semantics in other contexts, as @freebroccolo mentioned. And this is especially important in maths.

Then we agree people have different needs, and it would be nice to have variants to please everyone. But I bought this font for its Unicode support and because the ligatures bear a close resemblance to the glyphs that comprise it. Please show me a few ligatures of PragmataPro that do not respect this principle.

So having some variants does make sense, but I would like the reference PragmataPro font to continue with its original principle. This is the safest option to ensure PragmataPro to be used in any context, not just for a few persons. It improves readability without changing the semantics.

[CodeMonkeyMike]

@wismill IMO the '!=' '!==' and lack of '=!=' ligatures decrease readability not increase. Also this is a feature that some people want, people who don't use a ligature font for markup or math(s).

[nmcb]

I'm a bit late to the party, but I also would like =!= to be rendered as a long version of non-equals. A lot of library authors in Scala provide some (better) non-equality operator than build in != and they often choose =!=, e.g. spire.

[adrienne]

@fabrizioschiavi I would also like to request === and !== ligatures with three bars. Perhaps they can be in a stylistic set for those of us who want them?

[nmcb]

🥺

[Kikithecat12345]

Personally agree with the === and !== being 3 bars, but as a stylistic set.