Overall, it literally looks like a better Alacritty alternative. The creator(s) did a great job!
(I know you can fake scrollback search with tmux. It's not the same.)
I mean I can respect that, personally it isn't as a big of deal with me so I use ghostty on my mac but I would still think that I would advocate ghostty only after disclosing this to anyone to be really honest.
I can see why someone would feel attached to this feature though.
Mostly I’m looking forward to seeing it implemented so I can stop reading complaints about this being missing in every thread about ghostty!
@mitchellh seems to rely on the Ghostty feature to dump scrollback to a file, and edit/search over that.
I found it a bit too inconvenient when using remote systems frequently, though. (If I'm missing a trick, I'd love to use Ghostty! But I'm just not a fan of multiplexers.)
https://www.gnu.org/software/bash/manual/bash.html#index-rev...
It made for a more fun first experience with a terminal emulator than I expected to have.
Now the only feature I need in Ghostty is Windows support.
I use ghostty on my mac but have you forgot about ctrl + f to find things support in ghostty (I don't think it has ctrl f support iirc right?)
Update: Windows Terminal doesn't do it either.
I think I have "skill issue" regarding tmux and I used to use hyprland (recently went to niri) and I just always preferred opening up another terminal I used to use (which was foot back when I was using my own config and it was alacritty on cachy/ idk what was on omarchy for the time I was on omarchy but I don't like omarchy)
Is there actually a way to fix this skill issue, like I want something so simple in start that I just run it and forget and still get decent amount of benefits?
- It's generally bundled on most distros, or available for install in most default repositories.
- tmux sessions are available over ssh, so if I can continue where I left off over ssh (this is probably my main use case).
- I can full screen my terminal instead of having multiple terminals, and split in tmux. I usually split vim buffers, but then keep a terminal split beside it or in another tmux window.
- It's keyboard-driven, and universal across different window managers. Even if I switch from MacOS to Windows or to an X11 distro, tmux will still have the same keybinds using the same configuration language. I can also use vim keys to navigate the scrollback history.
- Its config language is simple enough for the modifications I personally need. I haven't felt that I need to learn the syntax beyond the basics.
- Knowing tmux is also a helpful skill for managing servers, which I do from time to time (my raspberry pi is still running a tmux session from when I last rebooted it).
* Spend some time learning keybindings and commands. Just an hour or two should be enough.
* Learn about the top plugins and install them. There's a plugin that saves and restores your session, I forget the name, but it's great
* If you use vim, set up both vim and tmux with the right plugins so that the same keybindings navigate across both vim and tmux splits seemlessly.
without tmux/screen though, it's much harder, even less reliable, to work over ssh, so it becomes natural need for such sort of tools.
Say I use screen and later tmux since I believe ~ 2010 but not using "advanced" features like "panes" and screen splitting every month, most of the time for me it's just switching between windows in session and different sessions (not that often) and that's all.
As a helper, for some projects, I do use predefined layouts (say first 4 windows opens with inventory dir, other 2 with root folder of ansible repo) so on, but need this also not very often, like when laptop reboots (which is every ~ 3 week on Win11 nowdays)
I see in config file, actions { "id": "User.find", "keys": "ctrl+shift+f" },
so probably I did
My terminal.app color scheme uses P3 colors on 7% gray rather than the usual sRGB colors so that I can use an OKLCH equidistant palette, and I make extensive use of shift-cmd-up to select and copy “the previous command’s output”. I considered switching for 24-bit color but ultimately I prefer not having to learn a new “rudimentary” app that’s deficient versus my nostalgia just like all the others, and it drastically reduces my stress level when working on other people’s devices that I am proficient in working with an OEM environment.
I occasionally use tabs but for the most part I prefer windows, so that I can drag them around and over/underlapped with other work I’m doing in my GUI. Not a big fan of screen and tmux except as their limited value to me in mitigating ssh disconnects when that’s a concern.
Perhaps your definition of power user is limited to uses aligned with your own?
Sigh.
I was clearly being flippant. Terminal.app does suck but if you’re happy in it then I’m not going to judge.
For what it’s worth, I cut my teeth on very limited terminals of the 80s and 90s too.
But I ended up writing my own terminal emulator because I wasn’t entirely happy with any of the options available these days.
Clarification: As noted above, Terminal.app is indistinguishably suck from all the rest in the areas that are materially important to me, so no meaningful gain in happiness exists with any current alternative. I enjoy one of the specific features it offers but I’d give that up the instant a relevant-to-me improvement over the status quo was available. Perhaps someday.
The built-in editor for all files had two modes, line-based and character based. In edit (char) mode, you edited the text file as usual. In line (command) mode, you selected lines and hit Return on them to begin execution there.
Commands were wrapped in curly braces; non-wrapped text was ignored.
The built-in phone directory was just a macro file with a dedicated keystroke; so you could structure and annotate it however you liked, and navigate it with search or with line-based mode up/down/pgup/pgdn as one would expect. Each entry was something like {dial 472627} {user x} {pass y} {ifca {goto :autologin_wwiv}} {end} with whatever niceties you enjoyed outside the curly braces.
It understood {gets} and {puts} from the modem tty (I don’t remember the actual command names) and it had conditional logic and substring index stuff.
If you needed human input, you could throw a {dialog} and get it, acting according to the result.
In modern parlance, imagine if your terminal emulator had ansible playbook support embedded into it and pressing alt-E popped up an editor for the playbook that let you start playback from any point in the script, JMP/GOTO-style.
You can see an example playbook at https://ftpmirror.your.org/pub/misc/dos/cavebbs/The%20Cave%2... inside PWRMC30S.ZIP. Read everything that isn’t a .MAC file first so that you know where to start reading. POWER.MAC is the main attraction; 53k of playbook macros serving as bionic assistance to TradeWars players.
My own archives are currently probably-lost unless I get very lucky someday, or else I’d share my own archive of playbooks built up over five years to auto-dial and auto-QWK hundreds of local BBSes for two-way mailing list packets.
For a long time I installed iterm2 because "that's what you do" but one day I realized I was suffering a little wasted disk space, slightly slower start-up, and slightly worse input latency, for... no reason, because I didn't do anything with it that Terminal.app couldn't do.
25 years on unixy operating systems. Spend tons of time in the terminal.