SSH & emacs cause phantom characters when trying to scroll down #251

Closed
opened 2026-01-30 21:46:52 +00:00 by claunia · 7 comments
Owner

Originally created by @Hyper200 on GitHub (May 10, 2018).

  • Your Windows build number: (Type ver at a Windows Command Prompt)
    Version 10.0.16299.309

  • What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)
    Using ssh, connect to a system and open a file using emacs, as you open the file press the down key to scroll.

capture

  • What's wrong / what should be happening instead:
    The file should open a scroll down, instead it adds a B to the top of the text file while it loads.

No entriley sure this is a console issue but the same issue dose not apply when using wsltty. Only seems to be an issue with emacs, I guess VI isn't in insert mode by default therefore it might not affect it.

Originally created by @Hyper200 on GitHub (May 10, 2018). * Your Windows build number: (Type ver at a Windows Command Prompt) Version 10.0.16299.309 * What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots) Using ssh, connect to a system and open a file using emacs, as you open the file press the down key to scroll. ![capture](https://user-images.githubusercontent.com/37409036/39864368-43491584-5441-11e8-8b3a-440242acd79b.PNG) * What's wrong / what should be happening instead: The file should open a scroll down, instead it adds a B to the top of the text file while it loads. No entriley sure this is a console issue but the same issue dose not apply when using wsltty. Only seems to be an issue with emacs, I guess VI isn't in insert mode by default therefore it might not affect it.
Author
Owner

@zadjii commented on GitHub (May 10, 2018):

What's TERM set to on the remote machine? A lot of issues like these are because the remote machine is set to something other than xterm-256color

@zadjii commented on GitHub (May 10, 2018): What's `TERM` set to on the remote machine? A lot of issues like these are because the remote machine is set to something other than `xterm-256color`
Author
Owner

@Hyper200 commented on GitHub (May 10, 2018):

Spot on

echo $TERM
xterm-256color

I guess the terminal has a general bug with xterm-256color? Or is there an altertive we should be setting.

xterm-256color must be the default for RHEL, CentOS etc.

@Hyper200 commented on GitHub (May 10, 2018): Spot on echo $TERM xterm-256color I guess the terminal has a general bug with xterm-256color? Or is there an altertive we should be setting. xterm-256color must be the default for RHEL, CentOS etc.
Author
Owner

@florian1984 commented on GitHub (Jul 10, 2018):

Im using vi with RHEL/SLES/Ubuntu, and got same problem (https://github.com/Microsoft/console/issues/188#issuecomment-391362285).

When I set => TERM="" => cursor key works, but page up/down not.
With TERM=xterm-color => page up/down works, cursor keys not

I could remap it in vimrc, but Im too lazy :-). With these bugs this m$ console is useless for me. Use now kitty (putty) again :-) ....

@florian1984 commented on GitHub (Jul 10, 2018): Im using vi with RHEL/SLES/Ubuntu, and got same problem (https://github.com/Microsoft/console/issues/188#issuecomment-391362285). When I set => TERM="" => cursor key works, but page up/down not. With TERM=xterm-color => page up/down works, cursor keys not I could remap it in vimrc, but Im too lazy :-). With these bugs this m$ console is useless for me. Use now kitty (putty) again :-) ....
Author
Owner

@Mythrix commented on GitHub (Jul 14, 2020):

Hmm I see that this issue is a year old, but I still have the same issue with emacs in CentOS 7.8 ssh'ed in from Windows Terminal.

When googling I found a thread for another console/terminal program ConEmu which had a similar issue with emacs: https://github.com/Maximus5/ConEmu/issues/1691

The top comment there seems to have some more detailed information about what the reason could be. Does that help in getting the issue fixed for Windows Terminal?

@Mythrix commented on GitHub (Jul 14, 2020): Hmm I see that this issue is a year old, but I still have the same issue with emacs in CentOS 7.8 ssh'ed in from Windows Terminal. When googling I found a thread for another console/terminal program ConEmu which had a similar issue with emacs: https://github.com/Maximus5/ConEmu/issues/1691 The top comment there seems to have some more detailed information about what the reason could be. Does that help in getting the issue fixed for Windows Terminal?
Author
Owner

@zadjii-msft commented on GitHub (Aug 22, 2022):

Hey this issue is... pretty dang old at this point. Anyone still seeing this? I reckon this is probably due to an input sequence getting chopped in half and not getting written to the console in a single write. Can we get a fresh repro here with a specific ssh version (and distribution)/?

@zadjii-msft commented on GitHub (Aug 22, 2022): Hey this issue is... pretty dang old at this point. Anyone still seeing this? I reckon this is probably due to an input sequence getting chopped in half and not getting written to the console in a single write. Can we get a fresh repro here with a specific ssh version (and distribution)/?
Author
Owner

@Hyper200 commented on GitHub (Aug 22, 2022):

i haven't had it since i switch to:
https://github.com/microsoft/terminal/issues/173#issuecomment-388091934

Thanks,

@Hyper200 commented on GitHub (Aug 22, 2022): i haven't had it since i switch to: https://github.com/microsoft/terminal/issues/173#issuecomment-388091934 Thanks,
Author
Owner

@zadjii-msft commented on GitHub (Aug 22, 2022):

That's kinda weird tbh, cause typically the Windows Console & Terminal should work with xterm-256color. I suppose your issue is sorted out, and we can just close this out for now. If something else like this comes up, we can track it in a fresh issue rather than this fairly stale one.

Thanks!

@zadjii-msft commented on GitHub (Aug 22, 2022): That's kinda weird tbh, cause typically the Windows Console & Terminal _should_ work with `xterm-256color`. I suppose your issue is sorted out, and we can just close this out for now. If something else like this comes up, we can track it in a fresh issue rather than this fairly stale one. Thanks!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#251