5 ms·

Ghostel.el: Terminal emulator powered by libghostty

307 points by signa11 3mo ago

freedomben 3mo ago
[dead]
jdormit 3mo ago
I recently switched from vterm to ghostel, and it is generally much, much better - noticeably faster (e.g. fancy TUI apps that try to refresh the whole terminal every frame actually work), more reliable input handling, and a nicer ELisp API. That being said, there are still some rough edges. Sometimes it fails to properly clear the terminal, leaving junk at the top of the buffer before the currrent prompt line. And on a couple of occasions it has totally frozen, with no fix other than killing the buffer and starting over. Overall, it’s very promising and totally usable as a daily driver, but it needs a bit of polish and bug fixes before I would consider it mature.
- baokaola 3mo ago
  Ghostel co-maintainer here: Understand if you don't have a repro, but if you ever have something actionable we'd love it if you filed an issue, or have the information get to us some other way. The junk at the top of the screen sounds like it could be https://github.com/dakra/ghostel/issues/495 https://github.com/dakra/ghostel/issues/495 and it should be fixed on later versions. But maybe you're seeing another bug. The tricky part is replicating the libghostty-vt internal data into an Emacs buffer while only replacing the parts that need to be replaced. We have property based tests to exercise this a lot, but sometimes things slip through. The latest released version as I'm writing this should have improved lifecycle handling, so maybe it also fixes some of your issues. As you say, the project is still in the early phase so hopefully, we can iron things out over time.
  - pingisland 3mo ago
    I also switched from vterm and ghostel is much more responsive for me. Thanks for maintaining it! I use it everyday. I do see a similar issue, where when I switch to the ghostel buffer and it wasn’t visible before, the text is scrambled. I’ll check if I can find a way to reliably reproduce it.
    - baokaola 3mo ago
      This is a known issue that I've been chasing myself. It most likely has to do with the fact that we cannot render hidden buffers (for reasons) so when the buffer reappears again, we have hooks to refresh it. But sometimes it fails to refresh fully. When are you mostly seeing this? With agent TUIs?
  - jdormit 3mo ago
    > The junk at the top of the screen sounds like it could be https://github.com/dakra/ghostel/issues/495 https://github.com/dakra/ghostel/issues/495 and it should be fixed on later versions Yes, that sounds like the same issue. I’ll update to the latest version and see if it’s resolved. And thanks for your work on this package, it’s been a real game-changer for me!
aftergibson 3mo ago
This is working great, it plus the Claude code integration has really adjusted how much I use Emacs. It's become a bit of a hub for me now.
- 4b11b4 3mo ago
  What do you mean by integration. Do you have a model driving emacs via server?
  - baokaola 3mo ago
    Maybe he's talking about claude-code-ide.el which piggybacks on Claude Code's IDE integration. It recently added support for Ghostel too.
    - aftergibson 3mo ago
      That's the one, having the chat interface to the side, with really nice support for various resume options and when prompting the CLI it's having reference to the buffer open has been very helpful.
deleted 3mo ago
[deleted]
dakra 3mo ago
Hi! Maintainer of Ghostel here. baokaola and I actually wanted to do a "Show HN" next week, but looks like someone was faster submitting the link. Have a look at the GitHub repo which is a bit nicer for a quick overview: https://github.com/dakra/ghostel https://github.com/dakra/ghostel To add some context, Ghostel is a terminal emulator for Emacs powered by libghostty-vt. There's a feature comparison vs vterm and eat: https://dakra.github.io/ghostel/#ghostel-vs-vterm https://dakra.github.io/ghostel/#ghostel-vs-vterm And here is a gist with images to compare performance and correctness: https://gist.github.com/dakra/4a0b76ebcf5d52338e13486437846574 https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465... But for me personally, it has not only replaced vterm/eat but also any other external terminal like kitty/Ghostty. Having your terminal text just like a normal Emacs buffer opens up so many possibilities and extension points that are just not available on any other terminal. Even simple stuff like searching in the scrollback, then navigating and selecting+copying a paragraph only with the keyboard. For every Emacs user that's so natural and fast in Ghostel while often cumbersome in other Terminals where I just reach to the mouse because it's easier. Happy to answer any questions and also like to hear feedback positive or negative. If you're an Emacs user and tried Ghostel and are still using Ghostty (or another external Terminal), is there something Ghostel is missing or is it just because you want some processes to run outside of Emacs? baokaola and I are also very active on GitHub, so feel free to open an issue if you have any.
- b3n 3mo ago
  Hi dakra! > is there something Ghostel is missing eshell allows me to manipulate text as I would in any other Emacs buffer. If I have a function which wraps a word in quotes, and bind it to a key, I can be confident it will work in eshell like it does anywhere else. It's a real killer feature. If I use evil-mode, or xah-fly-keys, or simply want to use ispell to correct the spelling of a word, it all works. Unfortunately with Ghostel none of this works. It's not integrated in the same way. There are extensions like evil-ghostel-mode, but they are limited. Are there any plans to improve this, or is it a limitation Ghostel has to live with? A Ghostel equivalent of eat-eshell-mode would be amazing.
  - dakra 3mo ago
ivanjermakov 3mo ago
> The native module is a prebuilt binary that auto-downloads on first use Why? Keep it a part of distribution.
- dakra 3mo ago
  That's because MELPA (and ELPA) doesn't have a way to attach platform specific files. It's all just git checkouts. That means we would have to check in the module binary for all platforms (>10MB together) if we want that it comes with the distribution. Also looking at e.g. jinx, another popular package that uses Emacs native modules, it does it like vterm and offers to compile on first usage. So as a Emacs package author, for a user friendly installation you can realistically only offer to download or compile on first use.
LtdJorge 3mo ago
I think the title should mention Emacs somewhere. A terminal emulator is different than a terminal emulator for Emacs.
- dakra 3mo ago
  I agree. And I would also prefer if the link went to https://github.com/dakra/ghostel https://github.com/dakra/ghostel instead of the documentation which is not that helpful if you don't know what the project is.
- canthonytucci 3mo ago
  .el = emacslisp file extension
  - lucasoshiro 3mo ago
    I know this only because I'm an emacs user. Outside that niche .el is an obscure file extension, so, no, it's not that obvious
  - Brian_K_White 3mo ago
    If you say so. I didn't know that, which supports the suggestion that the title fails to be meaningful. It's not the same as expecting the reader to know what a terminal is, just in case anyone was thinking of going there next.
    - iLemming 3mo ago
      > the title fails to be meaningful It's a weird flex to insist that the titles should always be extremely descriptive. It is already meaningful for the respected audience. Otherwise you can endlessly argue that a florist may not understand what "terminal" and "emulator" are, therefore it should be more descriptive for an occasional florist vising HN. For anyone who doesn't know what .el stands for, they'd click, see it's about Emacs and if not interested - close the tab and forget about it. Takes maybe a second. Not even a smallest imaginable deal - not big at all.
vijucat 3mo ago
Question: if I don't use TUIs or millions of lines of scrolling text, what am I missing by not using these newer terminal implementations? I use mintty on Windows and am pretty happy with it.
- JoeBOFH 3mo ago
  Honestly not sure. I used ghosty and others for awhile but had continuous issues of it not passing a compatible term variable so a lot of tuis would break.
  - adrian_b 3mo ago
    This is normally a problem only when connecting to a remote computer through ssh, if you have not installed there the terminfo entry for ghossty or kitty or whatever recent video terminal emulator you are using. If you do not want to or you cannot install the terminfo data, there is the easy workaround to put in your shell initialization script on the remote computer something like "export TERM=xterm-256color". Ghostty aims to be completely compatible with xterm, so everything should work fine after setting thus TERM, only the newer features of ghostty will not be available.
  - homebrewer 3mo ago
    https://ghostty.org/docs/features/ssh https://ghostty.org/docs/features/ssh
    - dakra 3mo ago
      Just want to add that we have the same feature in Ghostel. As it copies stuff to a remote host, automatic ssh injection is disabled by default but you can enable it by setting `ghostel-tramp-shell-integration` to true. For manual setup you can just copy a few lines from the manual in your shell: https://dakra.github.io/ghostel/#orgfea0bed https://dakra.github.io/ghostel/#orgfea0bed
- adrian_b 3mo ago
  Exactly as you say, the greatest difference with the recent generation of video terminal emulators that use the GPU through OpenGL or the like, is the much greater rendering speed, which becomes very noticeable with millions of lines of scrolling text, especially if you use high-resolution monitors. Unfortunately, millions of lines of scrolling text are no longer unusual, especially when you frequently compile big software projects. The use of high-resolution monitors has also been normal for many years. Instant window rendering is addictive, so now I would never return from a fast terminal emulator like ghostty to an older video terminal emulator. The last terminal emulator that I had been using before ghostty was kitty, which was also pretty fast in comparison with traditional terminal emulators, but I like ghostty more.
varjag 3mo ago
Been using it for bit over a month now. It's really nice that you can click on code references in Codex summaries and open them right there in Emacs buffers.
- dakra 3mo ago
  And not only mouse click of course, but you can use `ghostel-previous-hyperlink` (or ghostel-next-hyperlink) to quickly jump to the last hyperlink displayed. It also installs a repeat-mode map, so if you see 3 url or file links as output you can just `C-c C-p p p RET` and it will open the first link. I use that feature all the time.
parentheses 3mo ago
Ghostty has crashed nightly for me with ~10 terminals open across a few windows. So, I haven't been able to run it nor would I want to embed it inside anything I daily drive.
- vinniepukh 3mo ago
  cool story bro. feel free to make a github issue. I've been daily-driving Ghostty for years and i don't remember the last time it crashed on me.
- adrian_b 3mo ago
  I am running Ghostty 1.1.3, on Gentoo Linux. I have opened right now about a dozen Ghostty windows and about 20 tabs in each window, i.e. more than 100 shell instances. I have started in as many of them as I could, before becoming too bored, a "ls -lR" on a file system with many millions of files. I could not see any problem, much less any crash. I have been using Ghostty for a few months, very intensively, all day long, and I have not seen any crash or other suspicious behavior. If you have seen a crash, perhaps there was either some specific version of Ghosstty that had a bug, or, more likely, some weird interaction with some other software that you have, and which might be buggy, e.g. the GPU driver. (I am using an NVIDIA GPU.)
  - coffeeindex 3mo ago
    Just commenting to say I've had the same experience. Been using Ghostty since (I was aware of) its release and it has been buttery smooth ever since. I occasionally see people talking about crashing or other issues they've had with Ghostty but I've not seen anything of the sort.
- harmath 3mo ago
  [flagged]
zyralab 3mo ago
[flagged]
guskel 3mo ago
Thank you so much for building this. I've been wanting something just like this and I'm trying it now and it's amazing. I was struggling with vterm and now this might become my daily driver.
- iLemming 3mo ago
  It's legit nice. I have gone through vterm -> eat -> ghostel transition and this is a winner. At least for now.
iLemming 3mo ago
It would be nice to have some practical examples of how efficiently use its different input modes. On the surface the reasoning is straightforward - a terminal wants every keystroke. The editor also wants keystrokes for its own commands. These two desires are irreconcilable, so any editor-embedded terminal must have a way to switch "who owns the keyboard." That switch is a mode. There is no escaping it. But like people coming to Emacs from Neovim may get confused why is nvim +term has only two modes, but this one has 5, what's the point? Without clearly understanding the problem, the knee-jerk reaction might be "this thing is an over-engineered BS", while in truth Ghostel isn't more complex because it's over-engineered - it's more complex because it solves more of the problem - the extra modes are opt-in tools for tasks nvim simply doesn't address. But it's not super clear how in practice use that leverage efficently.
- dakra 3mo ago
  True. I'll have to update the documentation with some examples (and/or make a video?). I know you know them but I list the 5 modes quick here for readers: - semi-char: The default, where most keys go to the terminal but some common Emacs prefixes (M-x, C-c) go to Emacs - char-mode: ALL keys go to the terminal. This way you can run e.g. Emacs inside Emacs. - copy-/emacs-mode: This makes the whole buffer a pure read-only Emacs buffer and all keys go to Emacs. The difference between copy and emacs-mode is that copy freezes the terminal output (comes originally from vterm), while in emacs-mode new output keeps coming in (adopted from eat). - line-mode: It's like `M-x shell`, everything goes to Emacs but it's not read only but you can type text on the prompt. But nothing is send to the terminal until you press return. > why is nvim +term has only two modes, but this one has 5 I haven't used the neovim terminal, but I guess you can compare vim insert-mode with semi-char and normal-mode with copy-mode. And surely they have a char-mode as well, or can you not run nvim inside nvim (without having to press some quote key all the time)? That would leave only line-mode as the odd one out. > But it's not super clear how in practice use that leverage efficently As with all Emacs things, that's highly personal. Currently, I use semi-char mostly and switch to copy-mode to select/copy stuff. Very rarely do I use char or line-mode.
Ferret7446 3mo ago
Downloading a compiled module is a huge negative in the age of supply chain attacks; you're begging to get compromised.
- dakra 3mo ago
  This is just optional. I explained why it's not in the package in https://news.ycombinator.com/item?id=48881722 https://news.ycombinator.com/item?id=48881722 For all Emacs package updates, it's best of course to check the source what's changed and then you can compile yourself. PS, I also think Emacs is one of the few ecosystems where people actually check what changed. It's not like npm where you have a million of deps unreviewed pulled in. Personally I use borg and always at least quick check what changed, and most Emacs package managers have a similar feature.
  - jlokier 3mo ago
    Fwiw, in all my Ghostel updates recently, the Zig module failed to compile, with an error message from Zig about a line in the module source. I have a fairly up to date Zig installed via Homebrew. I didn't have time to fix it so downloading the binary module has been the only option. I had the same problem with vterm when I first tried it. The C module failed to compile, with a compiler error about a line in the source. As there was no downloadable binary module I fixed that one.
    - dakra 3mo ago
      > I have a fairly up to date Zig installed via Homebrew. This is likely the problem. Latest Zig is 0.16 and Ghostty (and therefor Ghostel) require exactly Zig 15.2. I just updated our code to have a better error message and make it clear that the problem is the Zig version. See https://github.com/dakra/ghostel/pull/541 https://github.com/dakra/ghostel/pull/541 jFYI, Ghostty issue to support 0.16 is here: https://github.com/ghostty-org/ghostty/issues/12228 https://github.com/ghostty-org/ghostty/issues/12228 So for your homebrew zig you probably have to: brew uninstall zig brew install zig@0.15
nihsett 3mo ago
Does ghostty have any features that makes it better than kitty in anyway? I keep seeing this all over the place, but I still don't understand why it's better than existing options. Can someone help who's used both help me, what's the elevator pitch for this, why is it worth checking out?
- lemontheme 3mo ago
  Having used it for three weeks before coming back to Kitty, my conclusions were that it’s a better terminal for people who need a terminal but don’t ‘live in’ their terminal. Ghostty just feels really polished and ‘native’ and it’s obviously faster than, say, iterm or the stock term on macOS. So Ghostty is what I would now recommend to anyone who just wants a nice terminal without the goal of turning it into a highly personalized IDE, like Kitty allows you to do. The only feature of Ghostty that I now miss in Kitty: setting the text size of each window pane independently. Oh and the slightly smoother quake terminal, even though I don’t use that much. Ghostty makes some choices that I personally find bizarre. For one, on macOS, cmd+, opens config in textedit instead of in $EDITOR. Another is there isn’t a key action for moving panes; you need to use the mouse. At least half of the config options are platform-specific. And weirdest of all scripting is limited and can only really be done with (get this) AppleScript. So, like I surmised (and I could be wrong, of course), Ghostty is just a nice terminal that lives alongside your other apps; Kitty is powerful enough to practically act like a second desktop environment (that is also cross-platform). Of course, this post is about libghostty, the underlying term emulator library. And that is an amazing contribution to the ecosystem! Zmx, herdr, soon neovim, now emacs, hopefully someday Zed – so many things can now embed an amazingly performant terminal
- neobrain 3mo ago
  [dead]
guillaume_code 3mo ago
[dead]

307 points by signa11 3mo ago

[dead]

I recently switched from vterm to ghostel, and it is generally much, much better - noticeably faster (e.g. fancy TUI apps that try to refresh the whole terminal every frame actually work), more reliable input handling, and a nicer ELisp API. That being said, there are still some rough edges. Sometimes it fails to properly clear the terminal, leaving junk at the top of the buffer before the currrent prompt line. And on a couple of occasions it has totally frozen, with no fix other than killing the buffer and starting over. Overall, it’s very promising and totally usable as a daily driver, but it needs a bit of polish and bug fixes before I would consider it mature.

baokaola 3mo ago
Ghostel co-maintainer here: Understand if you don't have a repro, but if you ever have something actionable we'd love it if you filed an issue, or have the information get to us some other way. The junk at the top of the screen sounds like it could be https://github.com/dakra/ghostel/issues/495 https://github.com/dakra/ghostel/issues/495 and it should be fixed on later versions. But maybe you're seeing another bug. The tricky part is replicating the libghostty-vt internal data into an Emacs buffer while only replacing the parts that need to be replaced. We have property based tests to exercise this a lot, but sometimes things slip through. The latest released version as I'm writing this should have improved lifecycle handling, so maybe it also fixes some of your issues. As you say, the project is still in the early phase so hopefully, we can iron things out over time.
- pingisland 3mo ago
  I also switched from vterm and ghostel is much more responsive for me. Thanks for maintaining it! I use it everyday. I do see a similar issue, where when I switch to the ghostel buffer and it wasn’t visible before, the text is scrambled. I’ll check if I can find a way to reliably reproduce it.
  - baokaola 3mo ago
    This is a known issue that I've been chasing myself. It most likely has to do with the fact that we cannot render hidden buffers (for reasons) so when the buffer reappears again, we have hooks to refresh it. But sometimes it fails to refresh fully. When are you mostly seeing this? With agent TUIs?
- jdormit 3mo ago
  > The junk at the top of the screen sounds like it could be https://github.com/dakra/ghostel/issues/495 https://github.com/dakra/ghostel/issues/495 and it should be fixed on later versions Yes, that sounds like the same issue. I’ll update to the latest version and see if it’s resolved. And thanks for your work on this package, it’s been a real game-changer for me!

aftergibson 3mo ago

This is working great, it plus the Claude code integration has really adjusted how much I use Emacs. It's become a bit of a hub for me now.

4b11b4 3mo ago
What do you mean by integration. Do you have a model driving emacs via server?
- baokaola 3mo ago
  Maybe he's talking about claude-code-ide.el which piggybacks on Claude Code's IDE integration. It recently added support for Ghostel too.
  - aftergibson 3mo ago
    That's the one, having the chat interface to the side, with really nice support for various resume options and when prompting the CLI it's having reference to the buffer open has been very helpful.

deleted 3mo ago

[deleted]

dakra 3mo ago

Hi! Maintainer of Ghostel here. baokaola and I actually wanted to do a "Show HN" next week, but looks like someone was faster submitting the link. Have a look at the GitHub repo which is a bit nicer for a quick overview: https://github.com/dakra/ghostel https://github.com/dakra/ghostel To add some context, Ghostel is a terminal emulator for Emacs powered by libghostty-vt. There's a feature comparison vs vterm and eat: https://dakra.github.io/ghostel/#ghostel-vs-vterm https://dakra.github.io/ghostel/#ghostel-vs-vterm And here is a gist with images to compare performance and correctness: https://gist.github.com/dakra/4a0b76ebcf5d52338e13486437846574 https://gist.github.com/dakra/4a0b76ebcf5d52338e134864378465... But for me personally, it has not only replaced vterm/eat but also any other external terminal like kitty/Ghostty. Having your terminal text just like a normal Emacs buffer opens up so many possibilities and extension points that are just not available on any other terminal. Even simple stuff like searching in the scrollback, then navigating and selecting+copying a paragraph only with the keyboard. For every Emacs user that's so natural and fast in Ghostel while often cumbersome in other Terminals where I just reach to the mouse because it's easier. Happy to answer any questions and also like to hear feedback positive or negative. If you're an Emacs user and tried Ghostel and are still using Ghostty (or another external Terminal), is there something Ghostel is missing or is it just because you want some processes to run outside of Emacs? baokaola and I are also very active on GitHub, so feel free to open an issue if you have any.

b3n 3mo ago
Hi dakra! > is there something Ghostel is missing eshell allows me to manipulate text as I would in any other Emacs buffer. If I have a function which wraps a word in quotes, and bind it to a key, I can be confident it will work in eshell like it does anywhere else. It's a real killer feature. If I use evil-mode, or xah-fly-keys, or simply want to use ispell to correct the spelling of a word, it all works. Unfortunately with Ghostel none of this works. It's not integrated in the same way. There are extensions like evil-ghostel-mode, but they are limited. Are there any plans to improve this, or is it a limitation Ghostel has to live with? A Ghostel equivalent of eat-eshell-mode would be amazing.
- dakra 3mo ago

ivanjermakov 3mo ago

> The native module is a prebuilt binary that auto-downloads on first use Why? Keep it a part of distribution.

dakra 3mo ago
That's because MELPA (and ELPA) doesn't have a way to attach platform specific files. It's all just git checkouts. That means we would have to check in the module binary for all platforms (>10MB together) if we want that it comes with the distribution. Also looking at e.g. jinx, another popular package that uses Emacs native modules, it does it like vterm and offers to compile on first usage. So as a Emacs package author, for a user friendly installation you can realistically only offer to download or compile on first use.

LtdJorge 3mo ago

I think the title should mention Emacs somewhere. A terminal emulator is different than a terminal emulator for Emacs.

dakra 3mo ago
I agree. And I would also prefer if the link went to https://github.com/dakra/ghostel https://github.com/dakra/ghostel instead of the documentation which is not that helpful if you don't know what the project is.
canthonytucci 3mo ago
.el = emacslisp file extension
- lucasoshiro 3mo ago
  I know this only because I'm an emacs user. Outside that niche .el is an obscure file extension, so, no, it's not that obvious
- Brian_K_White 3mo ago
  If you say so. I didn't know that, which supports the suggestion that the title fails to be meaningful. It's not the same as expecting the reader to know what a terminal is, just in case anyone was thinking of going there next.
  - iLemming 3mo ago
    > the title fails to be meaningful It's a weird flex to insist that the titles should always be extremely descriptive. It is already meaningful for the respected audience. Otherwise you can endlessly argue that a florist may not understand what "terminal" and "emulator" are, therefore it should be more descriptive for an occasional florist vising HN. For anyone who doesn't know what .el stands for, they'd click, see it's about Emacs and if not interested - close the tab and forget about it. Takes maybe a second. Not even a smallest imaginable deal - not big at all.

vijucat 3mo ago

Question: if I don't use TUIs or millions of lines of scrolling text, what am I missing by not using these newer terminal implementations? I use mintty on Windows and am pretty happy with it.

JoeBOFH 3mo ago
Honestly not sure. I used ghosty and others for awhile but had continuous issues of it not passing a compatible term variable so a lot of tuis would break.
- adrian_b 3mo ago
  This is normally a problem only when connecting to a remote computer through ssh, if you have not installed there the terminfo entry for ghossty or kitty or whatever recent video terminal emulator you are using. If you do not want to or you cannot install the terminfo data, there is the easy workaround to put in your shell initialization script on the remote computer something like "export TERM=xterm-256color". Ghostty aims to be completely compatible with xterm, so everything should work fine after setting thus TERM, only the newer features of ghostty will not be available.
- homebrewer 3mo ago
  https://ghostty.org/docs/features/ssh https://ghostty.org/docs/features/ssh
  - dakra 3mo ago
    Just want to add that we have the same feature in Ghostel. As it copies stuff to a remote host, automatic ssh injection is disabled by default but you can enable it by setting `ghostel-tramp-shell-integration` to true. For manual setup you can just copy a few lines from the manual in your shell: https://dakra.github.io/ghostel/#orgfea0bed https://dakra.github.io/ghostel/#orgfea0bed
adrian_b 3mo ago
Exactly as you say, the greatest difference with the recent generation of video terminal emulators that use the GPU through OpenGL or the like, is the much greater rendering speed, which becomes very noticeable with millions of lines of scrolling text, especially if you use high-resolution monitors. Unfortunately, millions of lines of scrolling text are no longer unusual, especially when you frequently compile big software projects. The use of high-resolution monitors has also been normal for many years. Instant window rendering is addictive, so now I would never return from a fast terminal emulator like ghostty to an older video terminal emulator. The last terminal emulator that I had been using before ghostty was kitty, which was also pretty fast in comparison with traditional terminal emulators, but I like ghostty more.

varjag 3mo ago

Been using it for bit over a month now. It's really nice that you can click on code references in Codex summaries and open them right there in Emacs buffers.

dakra 3mo ago
And not only mouse click of course, but you can use `ghostel-previous-hyperlink` (or ghostel-next-hyperlink) to quickly jump to the last hyperlink displayed. It also installs a repeat-mode map, so if you see 3 url or file links as output you can just `C-c C-p p p RET` and it will open the first link. I use that feature all the time.

parentheses 3mo ago

Ghostty has crashed nightly for me with ~10 terminals open across a few windows. So, I haven't been able to run it nor would I want to embed it inside anything I daily drive.

vinniepukh 3mo ago
cool story bro. feel free to make a github issue. I've been daily-driving Ghostty for years and i don't remember the last time it crashed on me.
adrian_b 3mo ago
I am running Ghostty 1.1.3, on Gentoo Linux. I have opened right now about a dozen Ghostty windows and about 20 tabs in each window, i.e. more than 100 shell instances. I have started in as many of them as I could, before becoming too bored, a "ls -lR" on a file system with many millions of files. I could not see any problem, much less any crash. I have been using Ghostty for a few months, very intensively, all day long, and I have not seen any crash or other suspicious behavior. If you have seen a crash, perhaps there was either some specific version of Ghosstty that had a bug, or, more likely, some weird interaction with some other software that you have, and which might be buggy, e.g. the GPU driver. (I am using an NVIDIA GPU.)
- coffeeindex 3mo ago
  Just commenting to say I've had the same experience. Been using Ghostty since (I was aware of) its release and it has been buttery smooth ever since. I occasionally see people talking about crashing or other issues they've had with Ghostty but I've not seen anything of the sort.
harmath 3mo ago
[flagged]

zyralab 3mo ago

[flagged]

guskel 3mo ago

Thank you so much for building this. I've been wanting something just like this and I'm trying it now and it's amazing. I was struggling with vterm and now this might become my daily driver.

iLemming 3mo ago
It's legit nice. I have gone through vterm -> eat -> ghostel transition and this is a winner. At least for now.

iLemming 3mo ago

It would be nice to have some practical examples of how efficiently use its different input modes. On the surface the reasoning is straightforward - a terminal wants every keystroke. The editor also wants keystrokes for its own commands. These two desires are irreconcilable, so any editor-embedded terminal must have a way to switch "who owns the keyboard." That switch is a mode. There is no escaping it. But like people coming to Emacs from Neovim may get confused why is nvim +term has only two modes, but this one has 5, what's the point? Without clearly understanding the problem, the knee-jerk reaction might be "this thing is an over-engineered BS", while in truth Ghostel isn't more complex because it's over-engineered - it's more complex because it solves more of the problem - the extra modes are opt-in tools for tasks nvim simply doesn't address. But it's not super clear how in practice use that leverage efficently.

dakra 3mo ago
True. I'll have to update the documentation with some examples (and/or make a video?). I know you know them but I list the 5 modes quick here for readers: - semi-char: The default, where most keys go to the terminal but some common Emacs prefixes (M-x, C-c) go to Emacs - char-mode: ALL keys go to the terminal. This way you can run e.g. Emacs inside Emacs. - copy-/emacs-mode: This makes the whole buffer a pure read-only Emacs buffer and all keys go to Emacs. The difference between copy and emacs-mode is that copy freezes the terminal output (comes originally from vterm), while in emacs-mode new output keeps coming in (adopted from eat). - line-mode: It's like `M-x shell`, everything goes to Emacs but it's not read only but you can type text on the prompt. But nothing is send to the terminal until you press return. > why is nvim +term has only two modes, but this one has 5 I haven't used the neovim terminal, but I guess you can compare vim insert-mode with semi-char and normal-mode with copy-mode. And surely they have a char-mode as well, or can you not run nvim inside nvim (without having to press some quote key all the time)? That would leave only line-mode as the odd one out. > But it's not super clear how in practice use that leverage efficently As with all Emacs things, that's highly personal. Currently, I use semi-char mostly and switch to copy-mode to select/copy stuff. Very rarely do I use char or line-mode.

Ferret7446 3mo ago

Downloading a compiled module is a huge negative in the age of supply chain attacks; you're begging to get compromised.

dakra 3mo ago
This is just optional. I explained why it's not in the package in https://news.ycombinator.com/item?id=48881722 https://news.ycombinator.com/item?id=48881722 For all Emacs package updates, it's best of course to check the source what's changed and then you can compile yourself. PS, I also think Emacs is one of the few ecosystems where people actually check what changed. It's not like npm where you have a million of deps unreviewed pulled in. Personally I use borg and always at least quick check what changed, and most Emacs package managers have a similar feature.
- jlokier 3mo ago
  Fwiw, in all my Ghostel updates recently, the Zig module failed to compile, with an error message from Zig about a line in the module source. I have a fairly up to date Zig installed via Homebrew. I didn't have time to fix it so downloading the binary module has been the only option. I had the same problem with vterm when I first tried it. The C module failed to compile, with a compiler error about a line in the source. As there was no downloadable binary module I fixed that one.
  - dakra 3mo ago
    > I have a fairly up to date Zig installed via Homebrew. This is likely the problem. Latest Zig is 0.16 and Ghostty (and therefor Ghostel) require exactly Zig 15.2. I just updated our code to have a better error message and make it clear that the problem is the Zig version. See https://github.com/dakra/ghostel/pull/541 https://github.com/dakra/ghostel/pull/541 jFYI, Ghostty issue to support 0.16 is here: https://github.com/ghostty-org/ghostty/issues/12228 https://github.com/ghostty-org/ghostty/issues/12228 So for your homebrew zig you probably have to: brew uninstall zig brew install zig@0.15

nihsett 3mo ago

Does ghostty have any features that makes it better than kitty in anyway? I keep seeing this all over the place, but I still don't understand why it's better than existing options. Can someone help who's used both help me, what's the elevator pitch for this, why is it worth checking out?

lemontheme 3mo ago
Having used it for three weeks before coming back to Kitty, my conclusions were that it’s a better terminal for people who need a terminal but don’t ‘live in’ their terminal. Ghostty just feels really polished and ‘native’ and it’s obviously faster than, say, iterm or the stock term on macOS. So Ghostty is what I would now recommend to anyone who just wants a nice terminal without the goal of turning it into a highly personalized IDE, like Kitty allows you to do. The only feature of Ghostty that I now miss in Kitty: setting the text size of each window pane independently. Oh and the slightly smoother quake terminal, even though I don’t use that much. Ghostty makes some choices that I personally find bizarre. For one, on macOS, cmd+, opens config in textedit instead of in $EDITOR. Another is there isn’t a key action for moving panes; you need to use the mouse. At least half of the config options are platform-specific. And weirdest of all scripting is limited and can only really be done with (get this) AppleScript. So, like I surmised (and I could be wrong, of course), Ghostty is just a nice terminal that lives alongside your other apps; Kitty is powerful enough to practically act like a second desktop environment (that is also cross-platform). Of course, this post is about libghostty, the underlying term emulator library. And that is an amazing contribution to the ecosystem! Zmx, herdr, soon neovim, now emacs, hopefully someday Zed – so many things can now embed an amazingly performant terminal
neobrain 3mo ago
[dead]

guillaume_code 3mo ago

[dead]