Hacker News new | past | comments | ask | show | jobs | submit login

So many people here are now praising texture healing, but to me its just half-way measure. Why are we as a community so resistant for adopting variable-width fonts? This texture healing already breaks perfect character cell grid, so in some ways it feels like worst of both worlds.

I feel at least partially the same about fancy ligatures; we could just use the actual characters in source code, Unicode is widely supported. Raku does that, but it would need better typesetting (with variable-width fonts) to really shine.




I hate ligatures in code.

It sometimes breaks out of the grid, but there still is a grid. Things are sometimes not micro-aligned but still macro-aligned, and that matters (to me).


If two character combination breaking the grid is acceptable then is three character combos ok too? What about four characters, or twenty? Where do you draw the line?


I draw the line at spaces, usually, because functionally there are usually spaces around where I care to have alignment.

But also, since I'm writing a character stream, I care about being able to see it as a monotonic stream of distinct characters (which is why I hate hate hate ligatures for e.g. "!=") and moving characters a tiny bit doesn't break that.


It only breaks the grid visually (and not by much); for layout purposes, which is what you depend on, the grid is still intact.

Why do we keep using fixed-width fonts? Because a lot of stuff has been written that depends on a columnar grid. Most notably, terminals are absolutely predicated on it and fundamentally cannot support any other mode of operation.

To begin with: visual alignment, ASCII art, diagrams using box-drawing characters, &c., both in code and in the output of diverse tools:

  def function_name(and_long_parameter_list,
                    so_that_it_wraps="like so"):
      pass


  ABC_D   = 1   # Explanation
  ABC_EFG = 2.0 # Another one
  ABC_HI  = 34  # A third one


  ┌────────┬─────────────┐
  │ Tables │ Using       │
  ┝━━━━━━━━┿━━━━━━━━━━━━━┥
  │ Cell   │ Box-drawing │
  │ Cello  │ characters  │
  │ Viola  │ ⋮           │
  │ Voilà  │             │
  └────────┴─────────────┘


  error: cannot find macro `behold` in this scope
   --> <anon>:1:13
    |
  1 | fn main() { behold!() }
    |             ^^^^^^


  $ ls -la
  total 43210
  drwxr-xr-x  17 root root     4096 Jan  1 23:45 .
  drwxr-xr-x  17 root root     4096 Jan  1 23:45 ..
  lrwxrwxrwx   1 root root        7 Feb 29  2020 bin -> usr/bin
  drwxr-xr-x   2 root root        0 Dec 31 23:59 boot
  ⋮
(I included the ⋮ in the box drawing table deliberately, because it demonstrates a weakness in the scheme: terminals and most monospacy text editors force stuff into the grid, just clipping or overflowing the cell if a glyph has to come from a fallback font, but most other things don’t, so you end up with visual alignment breaking if the fallback font used has different metrics. Also the whole East Asian Width thing and ucwidth and whatever is super messy. Your monospace font may or may not include the box-drawing characters, but it’s much more unlikely to include ⋮.)

Terminals are also built on columnar behaviour; there are escape codes for moving the cursor to such-and-such a line and column, for example, and things like a side-by-side split require columnar behaviour.

Text editors can go non-monospaced, but it breaks various content for the reasons discussed, and you’ll need monospace for any terminal because loads of stuff will break otherwise, so combined with inertia, even editors that support proportional fonts aren’t often used that way if they default to monospace.

(Me, I’d rather like to use a proportional font while editing, but I’m not moving off Vim for it, so I’ll probably never get it. But for presentation, I like to go at least partially proportional with the monospace font Triplicate’s Poly variant, which breaks strict monospaceness, widening characters like w/m/W/M and narrowing characters like i/j/l/1. As for what Monaspace’s texture healing, I like it most of the time, but am not sold on cases like some_function_w_, where the last two underscores are markedly shorter than the first and it feels unbalanced.)


I agree with that many present tools expect character grid, but moving away from character grid would be not as much work as it seems IMO.

Code can be aligned with elastic tabstops ( https://nickgravgaard.com/elastic-tabstops/ ) or virtual formatting (that things are aligned according to syntax regardless of whitespace).

Things to align in terminals are mostly tables, and they could be rendered as tables if the terminal supporting that knew that they are tables. Nushell natively supports tabular data structures, so rendering them as proper tables would need just one change – the table renderer.


To build on to sibling chrismorgan's excellent post, fixed-width fonts/ASCII art/Unicode drawing are a really elegant way to get 80% of what you'd ever want. Getting to 100% involves a full-on rendering system and markup which is 10x the work and complexity. To date, most people don't want that in their editor.


Yet the most popular editor is vscode which is browser based and has all the rendering tech just sitting there, largely unused.


I got an answer to a similar problem that VSCode needs working cursors out of the view where the text is not rendered. That is why it relies on the text grid for all layout and movement. https://github.com/microsoft/vscode/issues/142738#issuecomme...


Fair, but the markup bit is still killer. Imagine the engineering hours that have been spent avoiding writing plain old HTML.


thats not what it does - it maintains monoSPACE while chaning the characters to not look the same width -- the best of both worlds, if anything


Its ok but instead of uneven spacing you get uneven character widths.

It might be ok but there is a reason why type designers make every character to be the same and try to balance everything including spacing.

Monospaced fonts designs are dictated exactly by that limit of fixed character+fixed space.

But maybe the “healing” might not be verydistracting.


> there is a reason why type designers make every character to be the same and try to balance everything including spacing.

But this was designed by type designers. So you can make exactly the same argument about texture healing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: