I have been trying to diagnose an issue with LSP over TRAMP in Emacs, which I have documented in two github comments (https://github.com/emacs-lsp/lsp- mode/issues/2709#issuecomment-3311705879). The essential problem I have been encountering, is that the stdin in is used to pass commands to the shell, and then input to a process spawned by the shell. Some of the bytes meant for the newly spanned process are consumed by bash read-ahead and thus don't make it to the spawned process.
It really depends on what the standard input `type' is (pipe, tty, file, etc.). If you're forcing an interactive shell without a tty (a rare situation), bash assumes that you're trying to read from a script, but that you don't want the (non-interactive) script-reading behavior for some reason. The get and unget functions are minimal, and perform some minimal buffering. This is enough of a niche case that it's never been necessary to make them more complex.
If you're reading from a pipe, the behavior will be as you observe:
This behaviour only happens when readline is disabled, which seems to happen either with `--noediting` or when `INSIDE_EMACS` and `TERM=dumb are set. In this case the `getc_with_restart` function is used, and this in turn uses `read(fd, buf, 128)`, which may consume additional bytes.
It depends on what the kernel gives it. If you aren't using a tty, you'll get what's requested, possibly blocking.
I believe the `readline` implementation always only calls `read(..., 1)`.
Well, sure, it reads a byte at a time because it has to interpret what it reads as editing commands.
Unfortunately that also comes with a performance impact.
Single-character reads will always have a performance impact.
This feels like it is at least partially a bash problem, and I'm wondering if finding a way to resolve it would make TRAMP more reliable in general. I assume using readline is not the correct option, as this would interfere with emacs. It seems like there should be a way to allow the no readline behaviour to prevent read-ahead,
Only if you force interactive mode without a tty. Why are you doing that? Prompting? Job control? Is there some emacs requirement? Something else?
and maybe this should be the default behaviour unless some specific circumstances are met (e.g. reading from an actual file rather than a pipe, or only when not using stdin). Is anyone here familiar with the Emacs specific behaviour in bash?
I suppose if interactive is forced, and the input is a pipe (or otherwise
not seekable, but not a tty), and we're running under emacs, bash could
perform single-character reads, but it seems like an awfully special case
compensating for some strange circumstances.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
