emacs-libvterm
emacs-libvterm copied to clipboard
rlwrap doesn't work in vterm
Ref: https://www.reddit.com/r/emacs/comments/tp7el9/getting_rlwrap_to_work_in_vterm/:
I am using vterm as a terminal emulator in emacs. While running sml/nj repl in vterm rlwrap doesn't seem to work. (It works in other terminal emulators that I have: yakuake, kitty).
Any suggestions?
I'm experiencing the same issue.
This is a little bit too little information to help. It would be useful to have "steps to reproduce" and define what "doesn't seem to work" exactly means.
This is a little bit too little information to help. It would be useful to have "steps to reproduce" and define what "doesn't seem to work" exactly means.
Thanks for your elaboration.
Minimum steps to reproduce
- Launch vterm in emacs
- Type
rlwrap read
- Type Ctrl-e
- Expected: move cursor to the end of the line
- Actual: character '^E' appears
From terminal emulator like kitty, it behaves as expected.
Can confirm I've faced the same issue. e.g. using babashka on MacOS
rlwrap bb repl
Pressing the up arrow inputs <[[A
instead of cycling through the history.
Expected: move cursor to the end of the line
Actual: character '^E' appears
I have exactly the same problem. Does anyone know what could be causing this?
Minimum steps to reproduce
- Install/compile rlwrap 0.45 or later.
- Install ed editor
- Launch vterm in emacs
- Type
rlwrap ed
- Type Ctrl-e
Expected: move cursor to the end of the line Actual: character '^E' appears
Investigation
There is this commit here, in rlwrap's upstream, that explicitly disabled rlwrap working inside Emacs, not sure what was the reasoning behind though.
In the NEWS file you can now read:
when run inside an emacs shell buffer, rlwrap will execute the client in its place (just as when stdin is not a terminal)
This commit was added on 0.45 version, meaning rlwrap 0.44 or earlier might work inside Emacs.
It seems that you can skip the EMACS check by unsetting the environment variable INSIDE_EMACS, and after some very basic testing I have done, this seems to work.
Update
After further testing I realize that when using the shell mode (M-x shell) it all starts to make sense, the line editing capabilities of the shell mode would get in the way of rlwrap and vice versa, and that's probably the reasoning behind this specific change in rlwrap. If we unset INSIDE_EMACS in a shell mode and then run rlwrap ed
, we get a warning rlwrap: warning: Your terminal 'dumb' is not fully functional, expect some problems
and the terminal is scrambled. eshell mode also acts similarly, but not that bad.
Fortunatelly, both shell and eshell mode set terminal to "dumb", so maybe the check in rlwrap should be enchanted in a way that it checks INSIDE_EMACS variable but also check that the TERM variable is set to "dumb", otherwise act as normal.
Update 2
I have created an issue on the upstream, also created a PR.