I’ll start: After switching to Neovide from the terminal for Neovim, I got really hooked on the animated cursor and smooth scrolling (links to Neovide’s features page). It wasn’t until 2 months ago when the earlier was added to Kitty. I did so much overthinking about which terminal to use, and realized that I wouldn’t (and don’t) use most of the features provided by ones like iTerm and Kitty, though I picked the later. I was pleasantly surprised to see it added, even if it could use more work to make long smooth cursor animations like Neovide. The only other feature I want is smooth scrolling, I can’t believe there are no modern terminals with it.

(Somewhat) Side note: At this point many users realized that Ghostty got over-hyped, here is Mitchell Hashimoto’s (dev of Ghostty) thoughts:

https://mitchellh.com/writing/ghostty-1-0-reflection
Ghostty: Reflecting on Reaching 1.0 – Mitchell Hashimoto

I didn’t anticipate the hype. Some people think I am lying when I say this. I’m not. I’m not so naive to think that private betas and exclusive access don’t generate hype in principle. But I didn’t think many people at all would be interested in a terminal emulator. I thought I was building boring software for a niche audience. No hype! But I was wrong, and the consequences were real. People were frustrated that they couldn’t get in. People felt left out. People felt like I was being fake to generate hype. The waitlist grew larger than I was comfortable allowing in (given my prior stated priorities). I’m sorry about that. All I can say is that I didn’t intend for this to happen. I ramped up beta invites to try to get as many people in as I felt comfortable with (well, a bit beyond that). We ended the beta at around 5,000 users in a Discord of 28,000 at the time. Not quite the percentage of access I wanted for people but more than I could handle.
…

One more negative aspect of the hype is the expectation of Ghostty being revolutionary. It is and it isn’t. Ghostty has different goals and tradeoffs than other terminals. For those looking for those properties, Ghostty is a breath of fresh air and does things that no other terminal does. But for others, it’s just a terminal. And that’s okay. I hope you find a terminal that works for you and I don’t claim that Ghostty is the end all be all of terminals.

  • gnuhaut
    1·
    4 days ago

    This doesn’t seem like something a shell can implement properly. Well, except maybe you could make a shell+tmux hybrid, but that’s a terminal emulator running inside of a terminal emulator then (as are tmux and screen).

    The problem is that when you run e.g. ls, it prints directly to the terminal. The shell could, once ls finishes, reposition the cursor to the top and then print over the ls output, but that’ll just overwrite part of the ls output and ruin the scrollback buffer, which would be annoying.

    I think if you really wanted to implement this properly you’d need some sort of new feature (like an overlay layer maybe), implemented by the terminal, and then the shell would have to be patched to make use of that.

    • jokeyrhymeEnglish
      1·
      5 hours ago

      Okay, let’s go with xterm running bash, where the user ran ls, so xterm -> bash -> ls …

      • ls never talks to xterm directly, it’s stdout/stderr are provided by bash
      • bash effectively outputs a grid of characters to xterm, xterm doesn’t know about prompts or words or line feeds, just the grid
      • every time ls outputs a line, bash adds a row of output to the grid that it sends to xterm
      • if there’s not enough space for a new row, bash discards the top-most row, moves all other rows up by one row, and then inserts the row for the ls output

      Now imagine a hypothetical fork of bash or some other new shell …

      • the only thing different is the direction that the rows move off the edge of the screen when running out of space, that’s all

      Thus, this is entirely a shell problem, with a shell solution

      However, what I’ve neglected to mention so far is that terminal emulators and shells are almost certainly optimised for rows dropping off the top edge and new rows being added to the bottom edge

      So, the role of a terminal emulator in this scenario could be to provide ANSI control characters or other protocol for operating just as quickly in the opposite direction, sure