A Terminal Protocol for Program Status (OSC 7501)
mitchellh.com
  • lobsters__tuxes@crustaceanson.theshelf.topM
    1·
    13 days ago

    Nice!

    For the agent usecase, I didn’t want to use one of the tabbed harnesses, and so resorted to writing an agent harness plugin to infer this status, and then route that status from my server to my laptop, and if my agent session name and niri workspace names match, then the notification takes me to the right workspace.

    This is a gross hack that I’d prefer to just have my agent harness and terminal do out the box.

    score 1 · canonical

    • lobsters__dgl@crustaceanson.theshelf.topM
      0·
      14 days ago

      That’s more low level, STATUS is for example useful if output is hung and the user wants to see what is happening. This is for if the user isn’t looking at the particular terminal but the title/tab/notification wants to reflect an overall status.

      score 1 · canonical

      • lobsters__zie@crustaceanson.theshelf.topM
        1·
        13 days ago

        Why couldn’t the terminal just run the termios STATUS and use that to update the title/tab/notification? Linux doesn’t completely support STATUS, but it does exist. I’m not sure about other platforms.

        score 1 · canonical

  • lobsters__kolja@crustaceanson.theshelf.topM
    0·
    14 days ago

    Speaking as someone who basically lives in a terminal, I’m not sure if I’m a fan of this “browserification” of terminals. There are already ways to interact with a desktop session, and placing too much functionality in the terminal could lead to fewer neat ideas of what is possible by, you know, executing programs in it.

    If I want to direct my attention to something, I’m very happy with choosing between a notify-send, spd-say or curl ntfy.shor whatever. Just add a call this to “call” me option to your elevenhundredth agent harness if you so require.

    score 1 · canonical

    • lobsters__mitchellh@crustaceanson.theshelf.top
      0·
      13 days ago

      I think here we’d have philosophical differences.

      I’ve gone on record many times actually praising browsers as a model terminals should strive for (but, explicitly, at a much smaller surface area). I think browsers have gone too far on the spectrum towards OVER-THE-TOP application platform and terminals have gone too far on the spectrum towards STAGNANT application platform.

      My explicit goal with my terminal projects from the beginning has been to push that forward. I think my original talk I ever gave on Ghostty 3 years ago I said something like: browsers ship hundreds of features per year, I’d like terminals to ship like 10.

      Of course, I’m sure some people will disagree. And that’s fine, stay away from my projects and use something like xterm (which is fantastic and is our ground truth for historical specs).

      score 1 · canonical

      • lobsters__kolja@crustaceanson.theshelf.topM
        0·
        13 days ago

        Sure, to each their own. I’m also not criticizing your work, I’m just saying “I don’t want this.”

        I think browsers suffer because their features are not user-driven, and competition is very hard because of the huge surface area that needs to be implemented. I don’t want terminals to suffer the same fate, or go down a heavily feature-fragmented route. They are by design meant to interact with an environment where this type of feature coverage can be implemented by combining tools (think UNIX philosophy), defining “the one true way” in the terminal is antithetical to that.

        Just look at the many “this only works in Chrome” sites. That is not the path we should go down here.

        I’d like terminals to ship like 10.

        Speaking personally: please don’t. But if you insist, I think better a11y would actually benefit a good number of humans significantly.

        score 1 · canonical

        • lobsters__mitchellh@crustaceanson.theshelf.top
          1·
          13 days ago

          I have another comment on here about a11y… please see my comments for that full context. EDIT: Here it is https://lobste.rs/s/ifbdw1/text_mode_lie_why_modern_tuis_are#c_awixrd

          The best way to fix a11y is to ship MORE terminal specifications that are higher level. Right now one of the reasons a11y is so bad/hard in terminals is because a grid of opaque non-semantic cells is very difficult or impossible to reliably map to the semantic needs of a11y tooling.

          If we can ship more specifications that help elevate semantic state – such as program status! – but also things like semantic prompts (OSC133, not my spec), hyperlinks (OSC8, not my spec), progress (OSC9;4, not my spec), buttons, designated input areas, etc. Then we can start clearly mapping this to a11y state.

          Background on this one: I spent a day (just one day, but a full one at least) with the UW HCI lab that was doing a project on terminal a11y and we were able to brainstorm a lot of the shortcomings here based mostly on their far more experienced background. They were experts on a11y technologies and I was the terminal expert.

          score 1 · canonical

    • lobsters__pta2002@crustaceanson.theshelf.top
      0·
      13 days ago

      Not really, consider the use case of a TUI-ish application showing some progress bar. Having both stdout and stderr doesn’t solve the use case of wanting the terminal to know when it’s done. (in fact using both only makes the problem worse for the user by garbling the text!)

      score 1 · canonical

      • lobsters__mitchellh@crustaceanson.theshelf.top
        1·
        13 days ago

        Ignoring the fact stdout/stderr are already too widely used to force an in-band protocol on top of them, also consider a TUI-ish application that itself spawns 4 other applications that themselves have their own concept of progress. (Directed at linkdd, but piggybacking on agreeing with parents comment)

        score 1 · canonical

  • lobsters__tstack@crustaceanson.theshelf.top
    0·
    14 days ago

    no JSON

    I find this really frustrating.

    There’s always going to be new escape sequences on the horizon. Each one having their own custom serialization format is just going to slow down adoption and be a source of bugs. Using an established serialization format that just works and is readily available is not an unreasonable ask. It doesn’t have to be JSON. But, at this point, it has basically won. Every single example program mentioned in the spec is already dealing with JSON. Every shell environment that has base64 most likely has jq. What is supposedly being saved by not using it and instead making tool authors do something custom? It just adds more stops in integration hell.

    score 1 · canonical

    • lobsters__spc476@crustaceanson.theshelf.topM
      1·
      13 days ago

      But, at this point, [JSON] has basically won.

      Twenty years ago, XML won. XML was everywhere. I wouldn’t be surprised if twenty years from now, something else has replaced JSON as a serialization format because of its annoying aspects.

      score 1 · canonical