search

p3r7 / friendly-shell

:shell: More convenient Emacs shell APIs
MIT License
30 stars 1 forks source link

incompatibility with native-shell for remote interactive shells #1

Open p3r7 opened 4 years ago

p3r7 commented 4 years ago

I have a strange issue w/ my setup.

When spawning a remote interactive shell w/ friendly-shell or friendly-remote-shell and sending a cli command to the spawned shell, it sometimes hangs.

This seem to only happen with commands split in several words (e.g. apt search toto) and is not happening 100% of the time. Even more strange, it doesn't seem to happen when we copy/paste the command in the buffer but only when we type it (letter by letter).

It seems to hang when sending the command and not at the output processing / display stage. ^C allows to cancel the command and retrying it makes it work.

~~The problem seems to occur starting with Emacs 26.2 and is also present on 27.2. I'm not 100% positive about when things started to break. More precisely I don't know if it's an Emacs/TRAMP regression, a friendly-shell/with-shell-interpreter regression or due to another package I introduced.~~ (see next message)

p3r7 commented 4 years ago

Found the culprit!

It seems that I introduced native-complete in my setup.

It seems that ^[*^U echo ^Y gets (sometimes?) suffixed to the input commands (see native-complete-style-suffix-alist). This suffix sometimes get sent to the interpreter, stucking it. This must be native-complete/company doing its thing, for proposing completions back to the user. This explains why the issue occurs when typing commands but not when pasting them.

p3r7 commented 4 years ago

native-complete works fine when I spawn remote shell wo/ using with-shell-interpreter.

I can kinda prevent the issue by commenting out this line in with-shell-interpreter. This disables setting explicit-shell-file-name (which is in most cases redundant with setting shell-file-name as both gets looked up by most shell fn).

After checking out, native-complete doesn't seem to rely directly on this var!

So this must have to do with some lower-level comint/shell fn being called an crapping out silently.