[emacsomancer]

detect Emacs specific terminal environments (e.g. ansi-term, shell, vterm, eshell, ghostel) on Linux using environment hints and process ancestry

Summary

detect Emacs terminal environments and (where relevant) shell

Changes

• added functions for handling Emacs INSIDE_EMACS environment variable, and assigning names for terminals
• added functions for tracing Emacs provenance and relation to fastfetch process (avoid false positives, for one)
• added functions for handling Emacs shell (where relevant)

Screenshots

screenshots showing fastfetch running in emacs in graphical and terminal modes, with various combinations of Emacs terminal packages, shells packages, or external shells, and (for terminal modes) in different external terminal emulators.

Checklist

• I have tested my changes locally.

[emacsomancer]

Additional notes:

Limitations: fastfetch (both without this pull request and with it):

• 1. reports " Terminal Theme: #FFFFFF (FG) - #000000 (BG) [Dark]" when using Emacs with the ghostel.el, eat.el package/frontends in graphical Emacs
• 2. hangs momentarily and then output (instead of "Terminal Theme"): "�]10;?�\�]11;?�" when run in eshell in graphical Emacs
• 3. generates an error when attempting to calculate Terminal Theme when run in ansi-term/term.el in graphical Emacs: error in process filter: Args out of range: [term term-color-black term-color-red term-color-green term-color-yellow term-color-blue term-color-magenta term-color-cyan term-color-white], 9

[note: it seems like it should be simple to skip the terminal-theme detection when the Terminal itself is Emacs, but initialisation and order things make this complicated.]

Theoretical additional improvements: we could in theory manage to report actual terminal font for graphical Emacs frontends, but it's complicated because of needing to check in Emacs the: default font, default monospace font and what actually is set buffer-locally; and for that we'd have to trace the ppids ancestry and then make a special call to emacs to check this, and I'm not sure of a way of doing that generally, but only when Emacs was run as a daemon or later launched a "server", and so it would have to be a number of I think complicated conditions for checking this (and there could in theory be multiple active daemons or servers so that would have to be traced carefully, further complicating things) and skipped if the relevant buffer is launched neither by a daemon or server (and, I think, some of the check will depend on the buffer being displayed in an Emacs window, which it presumably should be if fastfetch is being called, only the checks and tracing while fast would not be instantaneous and there could be race conditions if the user switched which buffers were displayed quickly after calling fastfetch).

I'm not sure what to do about the terminal-theme issue (which is a pre-patch issue) - most solutions I can think of involve changes to initialisation order (which I would be very chary about trying) or adding somewhat otherwise redundant helpers (or, if not redundant, then somewhat code-tangling/obscuring) or just plain redundant and domain-inappropriate code ("setExeName()" in the theme section).

Also, note that this patch is currently Linux-specific. probably some of the code could be moved (requiring extensive refactoring at the very least) from terminalshell_linux.c to terminalshell.c (e.g. into something parallel to fftsGetTerminalVersion, i.e. something like fftsGetEmacsFrontend), but I'm not sure how to generalise the environment variable checking, combined with ppid tracing and all.

In theory, some of this, including what the pull request itself addresses, could be solved the other way round we could have emacs pass values into fastfetch rather than fastfetch trying to get at them. But this seems both like a mechanism that could be abused; a bit... top-heavy for single application; as well as also sort of against the spirit of fastfetch, as being (by default) sort of in charge of finding things out rather than being fed things.

Currently the most obvious mechanism, for, say, retrieving actual fonts being using inside of an Emacs graphical terminal/sell session, would be using an optional .jsonc configuration that could query Emacs (side-stepping the issue of finding out vs being fed in a way, because it wouldn't be part of the actual binary and would be optional), but in addition to discoverability issus, even that would seem to require at least Lua, and currently I don't know how widespread +LUA is as a typical configure for fastfetch packages (e.g., it's not on Guix or Nix but does seem to be on Arch).

Anyway, the current pull request does the more modest thing of extracting a little more information about its environment when in Emacs.

Though in theory perhaps this should be reported as a separate line item: since once could be running Emacs itself in terminal mode rather than graphical mode, and then we might want to distinguish (a) shell from (b) actual terminal from (c) Emacs mode/environment/interface. That is, Emacs run in terminal mode might report, e.g.:

[user running Emacs's vterm with fish shell]

• Shell: fish 4.9.3
• Terminal: xterm 411
• Terminal Interface: vterm (emacs)

or

[user running Emacs's eshell shell using the eat package's eshell mode]

• Shell: eshell (emacs)
• Terminal: alacritty 0.17.0
• Terminal Interface: eat (emacs)

as against, when vterm or eshell-in-eat were run in a graphical Emacs with the same things:

• Shell: fish 4.9.3
• Terminal: emacs 31.1
• Terminal Interface: vterm (emacs)

or

• Shell: eshell (emacs)
• Terminal: emacs 31.1
• Terminal Interface: eat (emacs)

[currently (pre -this-patch), fastfetch produces strange results for some of these combinations. post-patch "terminal" and the theoretical "terminal interface" are combined.]