Kitty Terminal 0.40.0 introduces the Text Sizing Protocol: "multiple font sizes ... in a backwards compatible, opt-in way"

Comments

• WorkingLemmy@lemmy.world ⁨1⁩ ⁨day⁩ ago

  I currently use gnomes console. Does kitty generally provide a better experience or is it simply a different option? Just curious! Love the text sizing protocol!

  source

  • TheTwelveYearOld@lemmy.world ⁨23⁩ ⁨hours⁩ ago

    You can see features & documentation on sw.kovidgoyal.net/kitty/

    source

    • WorkingLemmy@lemmy.world ⁨22⁩ ⁨hours⁩ ago

      Thank you so much!

      source
• sxan@midwest.social ⁨2⁩ ⁨days⁩ ago

  Golly, do I have mixed feelings about this. Both as a developer of TUI programs - in which determining the width of a widget is already a complex operation (same as in GUIs) - but also as a user who is already occasionally frustrated by double-width Unicode characters in terminals, which frequently don’t handle navigating such text well or correctly. I can only imagine the chaos this will introduce into text selection, text editors, and readline.

  OTOH, very cool. Unicode combining characters have great, mostly unrealized, potential, in no small part to consequential sizing issues.

  OTOOH, the world of computing is now a little more complex. Is the added complexity necessary, or just feature creep?

  source

  • TheTwelveYearOld@lemmy.world ⁨2⁩ ⁨days⁩ ago

    Like many things in tech, the command line was created when nothing like it existed before and over time it has gained unique traits that make it appealing (SSHing, programs tending to be open source and cross platform, mouseless UIs, etc.) but also lack things that alternatives, for instance multiple font sizes. Thus the need to reinvent the wheel like this. I made this post Is the line between TUIs and GUIs blurring? What’s the difference in rendering and compute demand between them? which got 64 comments.

    Same thing with the web really, a lot reinventing of the wheel of what OSes do, but there was nothing like it before where devices across the world communicate with each other, hence less need for things like sandboxing completely un-trusted code and a comprehensive app permission system (location, camera, etc.).

    source

    • sxan@midwest.social ⁨2⁩ ⁨days⁩ ago

      Ok, I’ll admit, I’m fascinated that you replied to me on Lemmy, but posted a link to a Reddit post. Are we communicating through a bridge, or do you just have so much time you can afford to be on multiple forum-style social media sites?

      Luckily, Reddit isn’t yet blocking the VPN exit node I’ve been using for the past week, but with any given node there’s a 50/50 chance I can’t see Reddit because they block VPNs pretty aggressively.

      But, back to the content of your message. You’re absolutely right: there is a trend of terminals slowly becoming graphics servers. I admit that whichever terminal I’m using in a quarter (I bop around a little bit, once every 4-6 months), I’ll stick with it longer if it:

      1. It supports ligatures
      2. It plays nice with tmux
      3. It supports Unicode character combining
      4. It supports some kind of graphics rendering, like sixel
      5. It is not unreasonably memory intensive

      There’s also a trend for terminals to include multiplexing, duplicating what tmux does, but tabs and navigation are wasted memory and code. Multiplexing in the terminal is, IMHO, the wrong approach; it doesn’t protect my session if the terminal crashes, or the WM crashes, or the GUI session crashes; and it doesn’t allow me to log out and back in, maybe to change WMs; and it doesn’t allow me to connect and continue from another computer. But, ultimately, I’m going to be using tmux for all of my remote servers and computers anyway, through ssh; why have a completely separate modality and mental model for the local terminal? So, for me, it’s just cruft in the terminal - extra code paths to contain bugs, extra memory use

      Ligatures really improve things, though, and with sixel and character combining, you’re really starting to veer into “display manager” space, as you say. Sixel -or Kitti’s protocol, or whatever that other one is - reduce the number of times I have to exit the terminal and reach for a GUI tool. But as you say, it’s just blurring the boundaries.

      Still, this feature is a step beyond. Ligatures and combining characters still kept things in a grid. Ligatures in particular just replaced 2 characters with a single-width, different glyph. Sixel graphics are graphics - we leave the realm of text behind, at that point. Multi-height, multi-width characters cross a boundary.

      It’ll be useful, though. This is why I’m torn. I’d love to see terminal markdown renderers be able to show proper super and subscript characters, and this would allow that. I only wonder whether the added complexity will be worth the little bit of extra eye-candy.

      source

      • -> View More Comments