feat(ghostel): new term module

[carlosdagos]

As discussed in https://github.com/orgs/doomemacs/discussions/116

Add a new term module for ghostel: https://github.com/dakra/ghostel

This module is heavily based in the existing vterm module in terms of coding style. No autoloads for poups or keybindings present for now.

Added flags to enable some of the ghostel modes that users may want, such as using it for compilation buffers, comint buffers, and eshell handoff to visual commands.

Note

1. I have purposefully ignored autoloads for popup terminals etc, as well as default keybindings to minimise the review burden, but happy to discuss and add them :)
2. The current pin for the packages is the latest version: https://github.com/dakra/ghostel/releases/tag/v0.38.0
3. Because the README is based off vterm, I just copied the [[id:...]] blocks and other thuings, but my org-mode skills are not that great so I may have fudged something.

---

• I searched the issue tracker and this hasn't been PRed before.
• My changes are not on the do-not-PR list for this project.
• My commits conform to Doom's git conventions.
• I am blindly checking these off.
• This PR contains AI-generated work.
• Any relevant issues or PRs have been linked to.
• This a draft PR; I need more time to finish it.

[panchoh]

Testing it as we speak, yay!

I’ve encountered an issue while trying the +eshell flag:

btop errors with ERROR: Failed to get size of terminal! (when running from an eshell, that is).
btop launches ok from a plain ghostel buffer, though.

If I add btop to eshell-visual-commands, like this:

(with-eval-after-load 'em-term
  (add-to-list 'eshell-visual-commands "btop" t))

then btop does not error, but the output is scrambled and laggy.

If I try to run nvim inside an eshell, it loads correctly, although some artifacts can be appreciated at the beginning. That don’t happen if I run it in a standard ghostel buffer, though.

The funny thing is that the same behavior can be seen (both nvim and btop) if I switch back from ghostel to vterm, so it looks like a bug on em-term.

At any rate, I thought I’d comment it here so that we know what to expect when testing this new module.

[panchoh]

This PR cannot be complete without another complementary PR to core:

https://github.com/doomemacs/core/blob/master/static/init.example.el#L80-L84

The funny comment! The hardest part! 😜

[panchoh]

Regarding the keybindings, I’d suggest just using the same vterm has, assuming that both modules can’t be active at the same time.

[hlissner]

Don't worry about updating init.example.el; I'll do that after this PR is merged, but in the near future, $DOOMDIR/init.el will be dynamically generated. The funny quotes will be extracted from the README.org's #+subtitle: (just try to keep it <=52 characters long).

Anyhow, thanks for this PR! I've wanted to try ghostel for some time now. I'll set some time aside to test, review, and merge this this weekend.

[panchoh]

Caveat Emptor: ghostel is available in nixos-unstable (and nixpkgs-unstable):

https://search.nixos.org/packages?channel=unstable&query=ghostel#show=emacsPackages.ghostel

but not the latest release (v0.38.0) this PR uses.

The project is very active, and we are not up to date yet.

[hlissner]

Posting this here so I don't forget later: as mentioned in dakra/ghostel#456, ghostel can rename its own buffer(s), which persp-mode won't like (because it stores buffers as names, rather than pointers), so buried workspaces may lose track of them.

A workaround appears to be setting ghostel-buffer-name-function to nil.

[dakra]

Thanks for including a ghostel module in doom :)

Just because I saw the PR, 2 quick notes/question:

ghostel can rename its own buffer(s), which persp-mode won't like

I know a few (/ a lot?) of users deactivate the buffer renaming, but personally I like it.
When working with multiple agents I can easily list all ghostel buffers and see which is which.
So maybe only deactivate when the user is actually using persp-mode? (not sure how integrated it is in doom and if everyone is using ist).

:hook ((ghostel-mode . mode-line-invisible-mode) ; modeline serves no purpose in a terminal

The user from the "Ghostel if fantastic" reddit post had that as well.
All personal opinion of course, but can I ask why the modeline serves no purpose in a terminal?

The only thing that's different and maybe less useful is the current line number.
Everything else like buffer-name, modes (inkl current ghostel-mode char/line/copy), your
clocked in org task etc is the same for a terminal buffer as it is for any other.