Programming ligatures and `locl`

Recently many programming typefaces provides ligatures for operators, i.e., `!=` will be look like `≠`. However some operators may have different meaning in different languages, for example, `/=`, the meaning of this symbol in Haskell differs from that in JavaScript.

So consider a similar situation that the same letter has different shapein different langauges, is it possible to provide different ligarues for different programming languages using `locl` feature?

Comments

  • attarattar Posts: 209
    locl lists languages, not programming languages.
  • It's worse than that.

    The features in these fonts don't mess with the underlying data stream - they provide ligatures which look like other characters but actually aren't them. So != will look (a bit) like ≠ but will not actually be ≠ - ≠ will be a distinct character; ... will ligate to an ellipsis but it will not be the same ellipsis as …; -> will look like → but will not actually be →, and so on.

    It's like mimic, only people are doing it to themselves.
  • @Simon Cozens 
    I am considering about creating some "quasi-ligatures" like `->` with the slash enlonged. However I do not think that providing `≠`-like or `≤`-like symbols is a good idea.
  • Ligatures don't actually change the underlying data; they're simply rendered glyph substitutions for the sake of looking nicer. So, yes, ligatures can be used in programming fonts without affecting the code itself.

    The bigger question I have is why a programmer would want ligatures distorting the visual representation of the code and making the differentiation between the various individual characters more difficult.

    I'm not a programmer, but I've been hand-coding HTML/CSS for many years. For me a good monospaced font, like Source Code Pro (which I'm using as I write this offline), is perfect.

    All this considered, there are instances in programming and scripting languages when a string of ASCII characters are used to represent a single token. So I suppose a -->, for example, being represented as an actual arrow occupying three monospaced slots might be visually preferable and understandable to some. Really, though, it seems to add even more confusion than it might eliminate. A better solution, in my opinion, would be better integration of Unicode into programming languages.
  • So I suppose a -->, for example, being represented as an actual arrow occupying three monospaced slots might be visually preferable and understandable to some. Really, though, it seems to add even more confusion than it might eliminate. A better solution, in my opinion, would be better integration of Unicode into programming languages.

    This is a terrible idea to switch '-->' to an arrow in a code environment. Because '-->' means the end to a comment block in a lot different languages – the arrow on the other hand does not mean anything. The code will still work but will confuse people quite bit. Coding fonts should never do anything like this (≠, --> ...).


  • attarattar Posts: 209
    A better solution, in my opinion, would be better integration of Unicode into programming languages.
    Agreed, yeah. Haskell has some beyond-ASCII codepoints syntax support: https://wiki.haskell.org/Unicode-symbols
  • Recently many programming typefaces provides ligatures for operators, i.e., `!=` will be look like `≠`

    Really? Is it just me, or is this terrible practice? 
    Personally, I don't think it's a question of changing underlying data or whatnot. Have you actually asked programmers if they'd like it?

    Staring at valid code patterns has a funny effect of burning itself into the brain, so substituting something as essential as a "!=" might actually be confusing. Scanning the code, using search & replace patterns, syntax highlighting... There's situations where you might be programming patterns that include the "!=" combination, but not as an "not equal", but as part of some string or other pattern. For example search all occurrences of "foo" followed by a space, followed by a "!=" followed by a space, followed by "bar" you might write as a regular expression like "/^foo\s\!=\sbar$/- your OT substitution is not context aware and will horribly distort the meaning and readability of a string like that.

    It's great typographers turn their attention to coding, but substitutions seem like a very bad idea to me (as someone with a programmer's background). You are talking about an activity where mistaking "'" for "’" can crash your business' servers, or the difference between "!=" and "|=" makes traffic lights switch from red to green - don't mess with what people are reading and writing and leave them with their ascii.
Sign In or Register to comment.