Hi Philippe, > The monospace restriction is a strong limitator: but then I don't see why a > "terminal" could not handle fonts with variable metrics, and why it must be > modeled only as a regular grid of rectangular cells (all of equal size) > containing only one "character" (or cluster?).
Because this is what a "terminal" currently is, this is one of the basic assumptions around which gazilliions of libraries and application were built up. Just one example: A utility might query the width, let's say it's 80 columns. Then it can print either 81 "i"s, or 81 "w"s, and in both cases it can be sure that the last one will be aligned exactly below the first one. You can sure change this. But then you'll have to heavily adjust the behavior of all the screen drawing libraries and all the applications that use these libraries or do their own screen handling. It's out of the scope of my work to do anything like this. If you feel like, I encourage you to go ahead, put your work in it, and present a proof of concept. > So using controls, you would try to mimic again what HTML already provides > you for free (and without complex specifications and redevelopment). Show me that "without complex specifications and redevelopment" because all I see is the need to heavily rewrite plenty of libs and tools that were created and continuously developed during the last few decades. I don't really see this approach feasible. Feel free to prove me wrong by presenting software that works on top of the redefined terminal emulator concept, at least on a proof on concept level. For starter, I'd love to see a shell with interactive line editing (like bash, zsh), and one application that uses vertical alignment heavily, let's say "top" or anything similar, using proportional font in your newly created world. cheers, egmont