> I’d like to use a (somewhat) wider range of basic symbols than whatever we had in ASCII last century. Even allowing comparison operators like ≤, <, ≠ and = that align consistently would be a useful start.
Visually, font ligatures do just that, and combine your !=, >=, etc. into single elements
But they don't actually work, because there are many ambiguities. Is <= "less than or equal" or an arrow pointing to the left? And in the other direction too: is ≠ "!=" or "/=" or something else? And as soon as you allow 3 or more characters to build ligatures, your number of ligatures explodes, but you still miss some.
For example it doesn't matter if <= is an arrow or LTE and => is an arrow, in a <=> all are wrong, same as in a >=> or a >>= or...
The main reason I stopped using programming ligatures that much is that many languages actually support Unicode characters in the source code, and this is actively used in some projects I work on.
It then becomes important to see the difference between ASCII approximations and real Unicode symbols, since this is relevant e.g. when searching for a symbol in your code base or to see at a glance whether usage of Unicode vs. ASCII etc. is consistent.
The only spot I still kinda use such a feature (prettify-symbols-mode specifically) is in LaTeX, where Unicode math is more rare and long equations become nearly unreadable without some kind of rendering in the source code.
I'm a bit confused. My only experience with ligatures is in vscode, I don't use them personally, but I've seen it where if you type >= then it changes it to look like ≥, if you hover over it, it shows >=, if you put your cursor to the right of it and hit delete, it deletes just the = and not the >, in other words, it is just >= except visually. On a git diff it would still be >=.
So I understand how you could have confusion in your case if you have logical comparators for ≥ and also have strings with "≥" or even variable names, if your language is permissive enough to allow that. But if you search for "≥" it should not return the ">=" disguised as "≥", ...right?
> But if you search for "≥" it should not return the ">=" disguised as "≥", ...right?
That’s my issue :). Languages like Julia permit both “>=" and "≥" in the source code with the same meaning. But if you use say search-based navigation of your file, how do you know which one to type to get where you want?
Or in Python I’ve seen some people make “alpha” render as α, since it’s a common variable name in physics codes. But “α” itself is a valid Python variable name, and I personally use Greek letters in Python physics code and know others do as well. That can again be confusing, since in Python “alpha” and “α” are not the same variable, so it’s crucial to write it correctly.
For vim/neovim users you can use digraphs, where you press `<C-k>` followed by a 2-character code to get a symbol (see `:help digraphs` and `:help digraph-table`).
For example,
<C-k> -> gives →
<C-k> => gives ⇒
<C-k> d* gives δ (greeks are generally all _letter_*)
<C-k> D* gives Δ
Some of the combinations are a little weird to rememeber, but if you use them regularly then it's easy enough (like greek or arrows).
In my editor I just press Ctrl+x, 8, Enter, and then I can look up Unicode codepoints based on either the hex code or the name. Alternatively you could do the whole Unix 'do one thing and do it well' thing and use a character selection program which allows you to look up a character (I've got KCharSelect, I believe Windows has a similar thing called Charmap or something).
- Like the sibling mentioned, you can use a “compose key” (it’s built in on Linux and can be installed on other platforms). There are other OS-wide options like the TeX input method for Gnome, or TextExpander snippets on Mac.
- In Vim, Ctrl-K in insert mode lets you enter “digraphs”. For instance, Ctrl-K *s will insert a Greek letter “sigma”.
- In Emacs, C-\ will activate an “input method” such as the “TeX” input method that can insert any math or Greek Unicode symbol using LaTeX notation. (I personally like Emacs’ “transient” input method that is activated for one symbol at a time, since it interferes less with coding.)
- In Sublime Text and VSCode there are third-party plugins that insert Unicode symbols via e.g. TeX notation.
- Every Julia editor extension, as well as its REPL, lets you press tab to convert a set of LaTeX-like notations into Unicode symbols in a common way.
- Most editors have support for snippets of some kind, and many have available snippet packs for common math and Greek symbols.
Depending on your operating system, you might have (the option to remap a key to) a compose key. Then you can press compose followed by, for example, <= to make ≤. This also works for letters with diacritics on them, like "o for ö or 'o for ó, currency like =C for € or =L for ₤, or other symbols like tm for ™.
You might also be able to set up your own compose codes in ~/.XCompose, but that didn't work for me. Could be another casualty of Wayland or just some quirk in my setup.
You've highlighted an issue with mapping syntax to ligatures in a generic sense, i.e, one that will work for programming language. But that's not an issue, because it's impossible, and we knew that from the start. When people make these stylized symbols, they have to write a parser for each individual language that they're applying them to.
Visually, font ligatures do just that, and combine your !=, >=, etc. into single elements