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 HashimotoI 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.
I don’t want to see the terminal emulator. No chrome. Needs solid emulation. That’s about it. Still using kitty and it’s got a good balance of stuff I use. I don’t really get the point of ghostty. These things are a bit like browsers, they just display the content and are interchangeable. People get super weird about terminal emulators and window managers.
I know it’s difficult, but I’d like for a terminal to have copy-paste work correctly, even over SSH. Most of my shell config fiddling has been trying to get copy-paste working through tmux+emacs+ssh in a way that doesn’t require xsel.
Other than that, one thing I’m missing from Alacritty is tabs. I know I can/should use tmux, but oftentimes I’ve launched a long-running command and then realized I want to do something else in another terminal.
If you want Alacritty with tabs, COSMIC Term uses libalacritty, so you get the same performance, but with tabs (among other things).
On quite a few terminals, alacritty is one, you can hold SHIFT while dragging to select things on the screen to copy from. This suppresses sending mouse events so works when you have editors, tmux or other things that can interpret mouse clicks. It does mean that it is just copying chars from the terminal so ends up copying everything on the screen. Unlike the copying baked into things like tmux of editors.
I dunno, they pretty much all work the same for me.
Me as well. My only real requirement is that the window supports transparency.
The only other feature I want is smooth scrolling, I can’t believe there are no modern terminals with it.
Seconded on both counts.
My terminal doesn’t “scroll” at all. Page up and down is all I need. I also don’t smooth scroll in my browser usually. Does it add anything? Isn’t smooth scrolling just worse actually (just like any other animation ever)?. The sooner the screen stops moving the sooner your eyes can lock on, focus and read. I never payed attention to it but you say it’s not widely supported, and that kinda makes sense to me. I can’t think of any reason to have it. I do lots of things in the terminal, I don’t even have a file manager. Smooth scrolling would make me slower and I would go crazy. Also you could scroll and end up with half a line visible on the top or bottom, which is just kinda weird and wasting space.
Try reading an entire epub book in scroll mode and you’ll see the use case.
- Distrobox, podman container support (listing, entering shell, color)
- Never open new windows
- Not GTK
- Normal name
- Not shady or proprietary
Otherwise Kate, Cosmic-Term or “ptyxis” are both fine
how does distrobox/podman stuff work? Isn’t this mostly just shell auto complete and making sure the typical escape sequences work?
You kinda chroot into a separate environment and have a shell in there.
So auto-indexing available shells, and coloring the terminal or something for every shell, would be useful
A shell where I can just copy and paste like a normal damn text editor (or using readline bindings).
How is me doing
Ctrl+[in tmux and then arrow keys to get to the line I want to copy, and thenCtrl+Spaceand thenAlt-w, and thenqmy best bet at this?I usually just reach for the mouse and do
Ctrl+Shift+Cinstead, but goddamn do I wish I didn’t have to.Also, what the fuck tmux - how is rolling the mouse bound to anything that anyone would want? And why do you inherit the shell you spawned from? Why not spawn as a new shell like everyone expects you to. Asshole utility.
Good touch support. Using termux has more then sold me on it, While many terms to support touch, I do often come across some that don’t. Otherwise i’m a simple man, be fast enough, work with one of the “major” image specs like sixel or whatever and do the basics and im set.
I don’t want all these fancy schmancy features. I’m very happy with foot in its current form. The only additional feature I would like is ligature support, but otherwise foot already has the features I want in a terminal emulator, and more that are optional for me (e.g. sixel support; although I do use sixels for my lf previewer, it is not necessary for me). I also don’t want my terminal emulator to have tiling, because rivertile does that for me, or whatever your window tiler is. Same for tabs. You can use i3 tabs, sway tabs, Hyprland groups, etc instead of having tabs in your terminal emulator.
AI cryptocurrency miner
and in the cloud
Terminal-as-a-Service
GPU Acceleration and a scroll bar I can drag.
I swear every terminal I’ve tried has one or the other but never both at once for some reason…I think xfce4-terminal has both?
Vim, but for terminal text manipulation. The closest I’ve found is Emacs vterm + evil, which is amusing.
Hear me out: I want the prompt at the top of the screen.
It’s terribly inconvenient to have the place you’re typping your command into at the bottom. On laptops, your fingers are in the way, and on desktops, you’re always craning your neck looking at the bottom-left.
Imagine instead if your terminal looked like this:
| ---------------------------------------------------------------------------- | | $ curl https://... | ---------------------------------------------------------------------------- | | $ echo "hello" | hello | $ ls | output.png | goes.txt | here.webm | ---------------------------------------------------------------------------- |After a command is entered in the upper pane, it’s appended to the lower pane along with the output just like a normal terminal. Maybe even something like translating
Shift+Enterto mean “clear the output pane and run”.Seems like a shell feature, and not a feature that a terminal emulator would implement
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.
Okay, let’s go with
xtermrunningbash, where the user ranls, soxterm->bash->ls…lsnever talks toxtermdirectly, it’s stdout/stderr are provided bybashbasheffectively outputs a grid of characters toxterm,xtermdoesn’t know about prompts or words or line feeds, just the grid- every time
lsoutputs a line,bashadds a row of output to the grid that it sends toxterm - if there’s not enough space for a new row,
bashdiscards the top-most row, moves all other rows up by one row, and then inserts the row for thelsoutput
Now imagine a hypothetical fork of
bashor 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
ls inherits stdout/stderr from bash, and then writes directly to that, which in this scenario is the pty (pseudo teletype) device created by xterm. Bash isn’t involved in forwarding that. The ls output goes via the pty device driver in the kernel straight to xterm, bash doesn’t see it.
In order for what you’re suggesting to work, bash would have to open up it’s own pty, which it doesn’t. But something like tmux does. Hence why I wrote you’d need to make a shell/tmux hybrid. The bash/tmux hybrid could then intercept the ls output and forward it to the xterm pty, like you are imagining. But tmux (or screen) are complex pieces of software, basically full terminal emulators. Adding an overlay (or whatever) feature to xterm for bash to use would surely be less complicated. Though I guess with how many terminal emulators there are, you’d need to convince at least the most popular ones to implement that (good luck). So both ideas, while theoretically possible, seem like non-starters. Too much thankless work and plenty of pushback I imagine.
