I tried a while back to invert my workflow (from tmux driving neovim to neovim driving terminals) because I thought it might be easier to only ever have one buffer open for a given file, instead of attempting to open a file in a given pane only to realize that it's already open in a different neovim instance in a different pane.
When I was testing that stuff out I don't think I noticed particular issues with text reflow that would benefit from being solved by swapping to libghostty, rather my pain points were just about how to adjust to the different paradigm. I'd be curious to hear more about someone who is all in on Neovim embedded terminals (and possibly how libghostty might make it better).
> I thought it might be easier to only ever have one buffer open for a given file, instead of attempting to open a file in a given pane only to realize that it's already open in a different neovim instance
This is not a problem in my config:
vim.api.nvim_create_autocmd({ 'FocusGained', 'BufEnter', 'CursorHold' }, {
pattern = '\*',
command = 'silent! checktime',
})
Also not sure how ghostty would help, haven't noticed text reflowing issues.
It's not bad, a little awkward getting used to:
- you might want a plugin to give you a "persistent" terminal across all tabs
- I still haven't found a way to clear scroll back while a command is running
- I had to set up mappings for easier exiting terminal mode (c-\ c-n really sucks)
- I had to set up events so whenever a terminal buffer is focused it immediately enters insert mode. While I love vim, I've never wanted modal editing in a terminal
Aside: I didn't realize Ghostty was written in Zig, wow. The first Zig-thing I'm aware of using on a regular basis. It's amusing the repository structure looks exactly like a Golang layout, haha.
Mitchell raised the issue himself two years ago: https://github.com/ghostty-org/ghostty/issues/189
but really not all features can make it in 1.0
Is there any particular reason?
I also like that I can have my config in a little plaintext file and just drop it onto a new computer and get the same keybindings. I am using the terminator keybindings for creating and navigating between split panes.
Also I just tried Ghostty for the first time. With iTerm2 and the Zsh/Powerlevel10k theme, there's an extremely brief but perceptible lag from running a command and the render. In ghostty it feels actually instant.
Example: Neovim is considering the switch to libghostty-vt when its ready. https://github.com/neovim/neovim/issues/33155
I never thought in a million years I would even think of ditching iTerm2 but when Ghostty dropped I installed it and fell in love.
I love ghostty, but if it keeps suddenly failing for no apparent reason I might have to go back to wezterm.
FWIW I've using tip since the closed beta and never had major issues.
solution: write a new VT terminal parser to replace the other ten
result: we have eleven different VT terminal parsers
I've looked into it with a PiZero and some HATs but I'd like something made by smarter people. This would be perfect for that.
Ideally just some dip-switchs to set the terminal to emulate and set the display resolution.
My router doesn't have a video port, but it does have a dummy terminal port. I had to scrounge a video card for my server to set it up, but it does have a serial port [3]. So that would have been nice.
Also would be nice for a modern remake of dumb terminal with abandoned monitors.
[1] https://www.cabling-design.com/references/pinouts/EIA-TIA-56...
Gruvbox light theme looks great too.
The fact it's written in Zig is awesome too, if you ever question if Zig is ready, ghostty is your answer to that.
Not seeing myself going back. It's great experience.
Tip: if you combine your ghostty flow with aerospace, it's nearly perfect setup for your keyboard only experience on mac.
Tmux copy mode is already great, my one gripe is no line numbers.
This script https://gist.github.com/Nimmidev/2cf4d5cc80dce32d0240ec7b3cf... is pretty good, but I still get frequent bugs with it, and also it just doesn't work in fullscreen mode (2 panes).
The core issue is that it's allocating a new tmux pane with the sole goal of mirroring line numbers; it would be nice if they synced up in the same pane, avoiding the above issue.
Piping it into neovim is an option that you can do on both neovim and zellij. zellij loses colors, and neovim is probably the best solution to this problem but then again I don't want to have to remember to turn on/off line numbers every time and I personally like one-off panes. Separation of responsibilities, I guess.
Long-winded rant to basically say: would a standard like this solve my issue easier? From what I understand of terminals, I would need to parse the underlying pty, maintain a scrollback buffer internally in the wrapper shim, and also be able to dynamically adjust toggling line numbers on/off.
If I'm doing this kind of translation, how "leaky" will the abstraction be until I'm basically re-implementing the logic in my middle layer, assuming that "for free" I can get the translation both in and out from the pty?
I've been trying to look closer at TUI tools, but that's what really bothered me. Given just how god awful the VT protocol is, you could get the state machine parsing correct, but the developer still has to learn basically every little quirk that was added over the years, no?
(And before someone makes a false equivalence, no, this isn't the case even with languages like c++ - I'm still learning quirks about it to this day, but I don't have to learn the entire thing to build proper, robust code. It does not seem the same with something like the VT protocol. So yes, I'm aware that some learning should take place, but I'm wondering how structured of a developer experience this will end up being.)
Oh oh oh!!!
> https://github.com/ghostty-org/ghostty/issues/1935
awww...
(while ghostty can parse Tmux Control Mode stuff, it doesn't actually implement the full feature. My dependence on iTerm2 remains...)
No, you're not but I did! So GPL then. Maybe I just wanted to make up a scenario. I'm not sure why MIT/BSD have become so popular, they have their place but I don't think they have any place in software infrastructure.
Curiously, it hasn't been discussed on HN before, so I started a thread to get HNers' thoughts on it:
The nix package for ghostty is broken/unavailable on MacOS at the moment, but installing the brew cask (`brew install --cask ghostty`) and a basic config file:
```
font-family = Monaco
theme = dark:Catppuccin Frappe,light:Catppuccin Latte
```
Got me almost everything I used from iTerm2. Nerdfont just worked (in iTerm I think you have to use the `Use a different font for non-ASCII text` setting)
- Still no ⌘F for find.
- No way (that I know of) to select previous output or specific string and copy with only keyboard shortcuts.
- No ⌘. sending CTRL-C (muscle memory and being advertised as native to the Mac is what one would expect).
- Fonts still don't render as nicely as in Terminal.app. I've fiddled with `font-thicken-strength` and it's close, but not quite. Probably impossible or very hard to replicate due to its Metal rendering nature, but when all you do is look at text all day, it matters.
asadm•2h ago