Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Libghostty is coming

mitchellh.com

Post reply on HN
Print view View original

41–50 of 275 posts

Re: Libghostty is coming

#41

Post by khamidou »

jrop wrote: post #11
jez wrote: post #5

Earlier quoted context omitted.

Do you consider yourself a neovim terminal power user? 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 do indeed live in the terminal (all day due to work), but tmux adds too much value for me to do all terminal management in Neovim (tmux session-management being what I use most). I've just encountered too many visual "glitches" in the Neovim terminal to rely on it for everything. That's not to say, however, that I never use the built-in Neovim :terminal. > I thought it might be easier to only ever have one buffer o…

I'd be curious to hear more about how tmux helps you — I tried it and besides keeping a permanent session open on a remote server to me I didn't find much use for it compared to regular terminal tabs

Re: Libghostty is coming

#42

Post by ldemailly »

bigwheels wrote: post #7

This is super cool, it will be so nice to have a truly omni-platform terminal emulator that can even conceivably extend to iOS and Android. 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. https://github.com/ghostty-org/ghostty

It doesn’t (look like a go layout) and that’s a good thing because pkg/ src/ etc aren’t good go directories.

Re: Libghostty is coming

#43

Post by ldemailly »

Pet_Ant wrote: post #32

I really want a little adapter that can plug into a monitor to make it a dumb terminal. Instantly on, no full OS, just a VT100 or something. 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.

Then what would you do? serial port? ssh? what is your terminal connected to if you don’t have an OS?

Re: Libghostty is coming

#44

Post by Igrom »

I want to use this to modernize vterm in Emacs. If I could only synchronize the terminal cursor and the Emacs point, and preserve lines as lines, not split them...

Re: Libghostty is coming

#45

Post by kortex »

hackitup7 wrote: post #10

I love how this guy founds + takes public + sells a multibillion company and then just goes right back to hacking. Legend.

Hashimoto is an absolute wizard, but what I find most compelling about him is his absolutely uncanny ability to segment and abstract systems and interfaces in a way for maximum composability and minimal entanglement. He's like the walking embodiment of Rich Hickey's Simple Made Easy philosophy. It's like he designs software systems in such a way that they have no choice but to operate correctly and predictably.

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.

Re: Libghostty is coming

#47

Post by sigbottle »

How easy would it be to implement a tmux shim application that just has line numbers natively in the pty itself for copying?

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.)

Re: Libghostty is coming

#48

Post by on_the_train »

I have a confession: I don't know the difference between a console, terminal (-emulator?!?), shell, bash and all these things. It's all just a black window with text for me. I've never understood why people talk so much about git shell when my normal windows cmd/Powershell can do just the same git commands. I'm also a prolific and successful software engineer. These two things shouldn't mix. So please tell me what I missed in life when these things are completely alien to me.

Re: Libghostty is coming

#49

Post by vinceguidry »

Really looking forward to this, writing my own personal editor in Ruby and not having a library for parsing terminal input is leading me to write my own kitty keyboard protocol parser (which ghostty implements) and having to hand-code lookup tables is driving me batty. I really don't like the idea of using an existing TUI framework as none of them actually implement the kitty protocol.

* https://sw.kovidgoyal.net/kitty/keyboard-protocol/#

Re: Libghostty is coming

#50

Post by esafak »

trial3 wrote: post #9

i desperately want to use ghostty but cmd+f support is just such a dealbreaker. excited about this development though!

Can someone explain why this was not one of the first features added? Who doesn't want to search their history? There must be some complication.

Mitchell raised the issue himself two years ago: https://github.com/ghostty-org/ghostty/issues/189

Post reply on HN