mnm
Ligatures in programming fonts
61–70 of 87 posts
Re: Ligatures in programming fonts
#62I use fonts with ligatures while programming because they're more expressive of intent. Many languages use a combination of characters to form a single meaningful token, such as JS with =>. This token is meant to appear similar to an arrow, and has nothing to do with = or >. In this case, I find it preferable to draw a ⇒.
> they're more expressive of intent. You don't control which font will be used when viewing your source, so nothing extra is being expressed to other people about your intent. Using a font with ligatures in your editor when you program doesn't record anything extra in the source code. > ⇒ I find it strange that you include the proper way of doing this instead of using font ligatures: use the proper Unicode code point…
Yeah, the APLer in me is strongly pro unicode, it's not like it would even be that hard for an editor to find di/tri/quadgraphs and replace it with a unicode glyph for when you just don't want to remember what incantation causes your keyboard to produce ⌹ (I'd go |:| for the trigraph).
Re: Ligatures in programming fonts
#63Interestingly, nobody mentioned Mathematica's (Wolfram langauge) approach of getting Unicode characters into code. "High level" mathematical symbols can be used in Wolfram language all over the place, for instance the arrow → indicating a Rule (http://reference.wolfram.com/language/ref/character/Rule.htm...) or ∞ indicating Infinity (http://reference.wolfram.com/language/ref/Infinity.html).
As Mathematica inherits the homoiconicity from LISP, ie. the paradigm "code is data", it abstracts the code representation (called "Forms", http://reference.wolfram.com/language/tutorial/FormsOfInputA...). Every shortened code full of greek symbols can be written in a completely similar form in ASCII. Thus it is solely to the Mathematica notebook (a Qt-based GUI) to render the Unicode. The GUI also allows to quickly enter any named symbols with an approach like typing "[ESC] alpha [ESC]" and an α appears (cf. http://reference.wolfram.com/language/tutorial/SpecialCharac...).
I think this is the right approach: Let the beautification to be done by the code viewers. The approach to enter named symbols probably stems from (La)TeX where one writes "$\alpha$" to get α and is typical to Computer Algebra Systems. For instance, SageMath as well as SymPy allow to define something like a=var("alpha") and render it like α.
Re: Ligatures in programming fonts
#64Do ligatures really act like one character? I've never encountered not being able to select only the f ro the i in a 'fi'-ligature, but I don't really use ligatures outside of word processing.
Re: Ligatures in programming fonts
#65Premise: don't make => look like ⇒, because ⇒ is already a separate thing.
Then later: check out this font I made where 0 looks like Ø.
Re: Ligatures in programming fonts
#66I think ligatures can be a great feature, but they should not be decided by the font, but by the editor. So you can can destinguish between 'input >> var' and 'vector >' and render the literature in one case but not the other. This and more creative text decorations can be really helpful to read code. Other examples are rendering css colors inline, rendering of tables and formulas in emacs, ...
They aren't implicitly decided by the font, they are supported (or not supported) by the font and explicitly decided by the editor, so your recommendation is the case in practice.
i.e. OpenType fonts optionally accept a range of settings flags to toggle various features. For standard ligatures this is the `liga` flag, this flag is off by default and an editor sets the flag to display ligatures (if the particular font supports that flag).
Re: Ligatures in programming fonts
#67Earlier quoted context omitted.
> they're more expressive of intent. You don't control which font will be used when viewing your source, so nothing extra is being expressed to other people about your intent. Using a font with ligatures in your editor when you program doesn't record anything extra in the source code. > ⇒ I find it strange that you include the proper way of doing this instead of using font ligatures: use the proper Unicode code point…
Yeah, the APLer in me is strongly pro unicode, it's not like it would even be that hard for an editor to find di/tri/quadgraphs and replace it with a unicode glyph for when you just don't want to remember what incantation causes your keyboard to produce ⌹ (I'd go |:| for the trigraph).
> APL ... ⌹
I really wanted to learn APL after seeing Conway's Life implemented[1] as one expression with no loops or temporary variables (using ⌹). Then I realized I would never remember how to type all of the {di,tri}graphs.
Re: Ligatures in programming fonts
#68Earlier quoted context omitted.
Yeah, the APLer in me is strongly pro unicode, it's not like it would even be that hard for an editor to find di/tri/quadgraphs and replace it with a unicode glyph for when you just don't want to remember what incantation causes your keyboard to produce ⌹ (I'd go |:| for the trigraph).
> APL ... ⌹ I really wanted to learn APL after seeing Conway's Life implemented[1] as one expression with no loops or temporary variables (using ⌹). Then I realized I would never remember how to type all of the {di,tri}graphs. [1] https://www.youtube.com/watch?v=a9xAKttWgP4
it's... easier than you might think? about half of them are relatively mnemonic and most of the others are close to a mnemonic (∩ is on 'c' but ∪ is on 'v'). If your on linux you can say set the windows key to shift over to an APL key binding (it's always present in KDE, in gnome enter gsettings set org.gnome.libgnomekbd.desktop load-extra-items true at a terminal then it will show up in the input menu)
and both Dyalog (free now for non-commercial use) and GNU APL (via Emacs) have secondary input methods until you get comfortable.
Re: Ligatures in programming fonts
#69The first problem isn't really a problem, since ligatures are provided by fonts, not character encodings. From the Unicode FAQ on ligatures and digraphs ( http://unicode.org/faq/ligature_digraph.html ): "The existing ligatures exist basically for compatibility and round-tripping with non-Unicode character sets. Their use is discouraged. No more will be encoded in any circumstances. "Ligaturing is a behavior encoded i…
This is exactly what I was going to say, and that one big issue I had when experimenting with ligatures for Hylang (a dialect of LISP) was that it did not keep the spacing of the original character combinations. While I thought the ligatures were much more concise, when they were disabled it shifted things around which ruined the indentation. It made the code ugly and hard to read for anyone not using them, so I had to give them up.
Hopefully one day we can all have language specific characters that make our code more concise. Until then I'll stick to fonts that keep the spacing of the original intact.
Re: Ligatures in programming fonts
#70Earlier quoted context omitted.
"A self-published eBook that acknowledges a lack of funding on the main page?" is kind of a low blow. He's doing something really interesting with the funding model of practicaltypography, that I believe should be praised.
I'm not meaning to deal any blows at all, low or otherwise. I'm merely explaining that to the reader not a student of typography, there's not really any indication that this should be taken with more authority than 'some blog author' per comments above.
From a brief bit of clicking around, the author has: designed several typefaces[1], written a long text on typography[cited previously], and has done enough programming to have developed the publishing framework he uses in his books[2], and to have written another book on a programming topic[3].
While I don't agree with much of this blog post, I certainly think the author has put in enough work to have their work taken seriously in this particular domain, and generally seems like a pretty interesting person.
1. http://practicaltypography.com/equity.html