-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for VT102 Insertion-Replace Mode (IRM) #1947
Comments
I suspect this is because the Windows terminal doesn't yet support Insertion-Replacement Mode (IRM). |
Interesting! Didn't know IRM was a thing. I'm going to repurpose this as a task to implement IRM. Notes: Insertion-Replacement Mode (IRM)
Set selects insert mode and turns INSERT on. New display characters move old display characters to the right. Characters moved past the right margin are lost.
Reset selects replace mode and turns INSERT off. New display characters replace old display characters at cursor position. The old character is erased. |
Yet another symptom of the same bug: Resize the window to 63 columns. Start Expected: The bottom row should display 9 buttons, each of them being 2 characters for the function key number + 5 for the action. The rightmost should be Actual: What the S-Lang library does is an ancient and obsolete hack for some terminals that don't have "pending wrap" (@j4james do you know more about them?), to print in the lower right corner without the cursor automatically wrapping to the next line and shifting everything up. It prints the intended last letter ( Even at bigger window sizes, such as the normal 80 columns, This is a tiny inconsistency (almost-bug) somewhere in S-Lang, my wild guess is that it could be related to non-color attributes (in this case italic) being used there, but I don't think it's worth investigating S-Lang's behavior any further. Also, for the record: I couldn't reproduce the issue with |
I know DOS and the original Windows shell didn't support "pending wrap", but then they wouldn't have supported By the way, |
this is a a real issue. pico editor seems to use this when ran under emulated xterm. and the characters do not move to the right like they are supposed to. still an issue as of this day. |
I'm also affected by this. Is there any known way to work around it? |
I was actually looking into this recently, and I think it's going to require some architectural decisions before we can consider implementing anything. I'd initially thought that the As things currently stand, I don't think this is possible. So either the inserting must be handled in the Considering the additional complications that are going to be introduced to the layout as we expand the VT functionality, I think the latter option may well be the best long term approach. But that is going to require some additional APIs, e.g. to query how much space a string of text will occupy and/or where it would be clipped. |
I also have the same problem, but I have a workaround. FreeBSD uses termcap (rather than terminfo) and the termcap entries for xterm include the 'im' and 'ei' capabilities which invoke the VT102 IRM. In the Linux terminfo database, these capabilities are not implemented. The workaround is to create a .termcap file in your home directory with this one entry in it: This will use this instead for the xterm-256color terminal (which is what Windows Terminal is), and delete the 'im' and 'ei' capabilities. Until the IRM capabilities are implemented, this works perfectly. |
It's wild how IRM works with line wrapping in xterm (351). Text is pushed off the right margin, as expected, but when the inserted region is wider than will fit it wraps and pushes text on the next line to the right. This is a terribly specific feature. I wonder why it was introduced! |
no version of xterm has ever not supported IRM. if you're not going to implement it, please identify yourself as a VT100 instead of xterm256-color. the pending-wrap thing is a side show, don't worry about it. just please make :ei=\E[4l: and :im=\E[4h: work. i've gone back to konsole as a result of this bug. |
I have to use putty because of this STILL, even though putty doesn't have perfect xterm emulation either. For those of you who can't seem to reproduce this, your pico is actually nano, which has a workaround for this bug. If you actually use the pico text editor, you can very easily see the behavior. it's the simplest test case. |
Thanks, your workaround fixes some weird behaviour when connecting to FreeBSD boxes. Waiting for a real fix ;-) |
Marc Reymann writes:
> ...
Thanks, your workaround fixes some weird behaviour when connecting to
FreeBSD boxes. Waiting for a real fix ;-)
freebsd is not the only place this matters. other systems also expect that
if the offered terminal type is xterm256-color, then IRM will work. my
workaround is to use TERM=vt100, which means, my workaround is to use
konsole instead.
|
Great!! I was dealing with this bug since April, it was really annoying. I just apply the workaround with |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Yes it is setting the TERM variable to VT100
|
I am just using tmux to prevent insert mode before the last space in a command. The Issue only happens to me when editing a command from the history.
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Numan Zaheer Ahmed wrote on 2022-12-11 15:32:
Can't SSH into a lot of lab/course(from Coursera, Udemy, etc.) VMs
because of this.
Any workarounds for this?
don't use microsoft's terminal emulator. stick with securecrt, or
install linux or freebsd inside "hyper-v" and run your terminal sessions
inside the client VM. neither microsoft's "terminal" or "ssh" are ready
for prime time.
|export TERM=vt100| did't work.
i should have been clearer. "export TERM=vt100" is what you do on the
remote system after you log in. the sshd that launches your shell there
is going to pass the TERM variable it gets from the ssh session. i have
not figured out how to get this to be passes as "vt100" by the invoking
ssh inside the powershell or command CLI on the initiating side. but if
i override it on the remote shell, everything i invoke there hears that
my terminal type is "vt100".
i guess coursera and udemy don't have shells and the TERM variable their
sshd gets from your ssh has to be correct? sorry about my ignorance, i
don't use ssh that way.
…--
P Vixie
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Numan Zaheer Ahmed wrote on 2022-12-11 15:58:
...
It's ssh on WSL2(which is basically a VM now) so not Microsoft ssh. As
for windows terminal, not using it is not solution. Good alternative
console emulators/terminals are hard to find on Windows.
if you're using WSL2 you might try mintty which claims to run there and
is based on putty which has working xterm escape sequences like IRM.
I ran the command inside the remote system after I logged in. Still
didn't work. ... Thx anyways. I should have mentioned where I ran it.
can you say more about what doesn't work and under what conditions? i
find that once i set TERM=vt100 (or TERM=vt220) on the remote shell, all
the text editors and screen oriented utilities stop trying to use IRM,
and thus work passably well with Windows Terminal.
i'm using Windows Terminal Preview but i just tested and it's the same
for Windows Terminal as shipped from the microsoft store.
…--
P Vixie
|
This comment was marked as off-topic.
This comment was marked as off-topic.
depending on the remote shell choice, it may not notice that you've
changed the TERM variable. more reliably, the commands you run from that
shell will inherit the modified environment (TERM=vt220 or whatever). to
be sure you're getting shell-level behaviour effects warranted by your
new terminal type, do something like this:
export TERM=vt220
exec bash
or, if you're like me using csh:
setenv TERM vt220
exec tcsh
or if you're using a modern mac/os ssh server-side:
export TERM=vt220
exec zsh
and so on. but your best test is still:
export TERM=vt220
emacs -nw $somefile
if your TERM indicates IRM and your terminal doesn't implement IRM then
emacs (among other utilities) will not be able to keep your screen updated.
Numan Zaheer Ahmed wrote on 2022-12-12 13:04:
|
This comment was marked as off-topic.
This comment was marked as off-topic.
This is still open 3&&1/2yrs later? |
The main issue here is UnicodeStorage, which is not very friendly to trying to do this. #8000 needs to finish first, and then this can be solved. |
I've recently removed That said, I've already begun working on this. :) |
This PR add support for the ANSI Insert/Replace mode (`IRM`), which determines whether output characters are inserted at the active cursor position, moving existing content to the right, or whether they should overwrite the content that is already there. The implementation is a bit of a hack. When that mode is enabled, it first measures how many cells the string is expected to occupy, then scrolls the target line right by that amount before writing out the new text. In the longer term it might be better if this was implemented entirely in the `TextBuffer` itself, so the scrolling could take place at the same time as the content was being written. ## Validation Steps Performed I've added a very basic unit test that verifies the mode is working as expected. But I've also done a lot more manual testing, confirming edge cases like wide characters, double-width lines, and both with and without wrapping mode enabled. Closes #1947
🎉This issue was addressed in #14700, which has now been successfully released as Handy links: |
works! tyvm. |
Insertion-Replacement Mode (IRM)
Set selects insert mode and turns INSERT on. New display characters move old display characters to the right. Characters moved past the right margin are lost.
Reset selects replace mode and turns INSERT off. New display characters replace old display characters at cursor position. The old character is erased.
original issue body follows.
The following is from recording command line editing in an ssh session to a freebsd environment (via FreeBSD's script). The displayed text is odd in Windows Terminal. First I show a textual form that shows the escape sequences and such in a readable form (I eliminated bell-ring characters from the file and other lines of text):
A normal display in other environments (for example macOS terminal doing an ssh into FreeBSD) looks like:
(The above shows the actual ls command that was executed.)
But under Windows Terminal (Preview) it shows:
This is also how it ends up looking during the command line editing,
not showing the actual text of the command to be executed: missing
some text.
The sequence is from deciding to add "-lTdt" after having typed the
path. (It was a "set -o vi" type of command line editing context.)
I was using TERM being xterm-256color on FreeBSD .
The text was updated successfully, but these errors were encountered: