1. 13
  1.  

  2. 2

    This is insanity, and I’m glad I’m not the one trying to tame it. At what point do we built a new protocol, instead of just trying to shoehorn more and more features into the old? When each semantic feature (like drawing) has n different extensions, with each client supporting a different set of these extensions, we’ve just got a huge mess.

    Why can’t we have something simple and stable enough to be common ground, the way LLVM has a documented IR - allowing new languages to be added by building only a front-end, and new target arches to be added without having to build yourself a new compiler for each input.

    1. 3

      Why can’t we have something simple and stable enough to be common ground, the way LLVM has a documented IR - allowing new languages to be added by building only a front-end, and new target arches to be added without having to build yourself a new compiler for each input.

      I think you’re overestimating the compatibility of LLVM frontends and backends. At $work we have an LLVM frontend which works nicely with LLVM’s x86 backend and our own, but we frequently run into issues with other LLVM backends - for example the PTX backend (used to target Nvidia GPUs) doesn’t support quoted names (which allow using special characters like ‘-’ in label names) or even the basic dwarf info our frontend emits.

      So the situation with terminals and escape codes is actually pretty close to what we have with LLVM, you get a small set of basic features that work everywhere and anything else might or might not work :).

      1. 1

        I am writing up a new bitmap protocol as we speak, actually–I didn’t want to attempt it until I’d mastered all the existing ones and actually used them in a non-trivial program. The most important thing IMHO is to center the protocol around the cell concept, since cells are the native semantics of a terminal. Rather than having to cut regions out with 0 alpha, I want to be able to cut a region by transmitting geometry to the terminal. Rather than redraw a bitmap somewhere else and then redraw all the cells under the old place, I want to be able to say “move this bitmap” (Kitty’s protocol supports this, good job Kitty). Rather than clutter my rendering/rasterizing loop with manual invalidations, I want to be able to (probably with an escape sequence) direct text under or over a bitmap.

        Of course, getting buyin from terminal authors will be an uphill struggle, but I think terminal authors reject the bitmap idea right now exactly because it’s so poorly mated to the terminal concept. Give them one that’s clearly thought out and well-tuned to the problem, and show them what can be done with it, and maybe it becomes as much a must-have feature as good ol’ SGR. Or maybe not, and my past year’s work is a farce. Time will tell.

        You say you’re working on this as well – what project? Feel free to hit me up for help or just to bounce ideas, nickblack@linux.com.

      2. 2

        Some notes from my recent experience integrating Sixel-, Kitty-, and iTerm2-style bitmap graphics into a z-ordered TUI system. It ended up significantly more complex than I had expected, due mostly to impedance mismatches between the methods and our objectives.