Repository navigation
Add support for VT102 Insertion-Replace Mode (IRM) #1947
Description
Insertion-Replacement Mode (IRM)
ESC [ 4 h
033 133 064 150
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.
ESC [ 4 l
033 133 064 154
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):
more ~/odd_commnd_line_editing_display.txt
ls ~/sys_typescriptsESC[1ESC[4h-ESC[4lESC[4hlESC[4lESC[4hTESC[4lESC[4hdESC[4lESC[4htESC[4lESC[4h ESC[4
A normal display in other environments (for example macOS terminal doing an ssh into FreeBSD) looks like:
cat ~/odd_commnd_line_editing_display.txt
ls -lTdt ~/sys_typescripts/
(The above shows the actual ls command that was executed.)
But under Windows Terminal (Preview) it shows:
cat ~/odd_commnd_line_editing_display.txt
ls -lTdt ~ypescripts/
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 .
Activity
j4james commentedon Jul 12, 2019
I suspect this is because the Windows terminal doesn't yet support Insertion-Replacement Mode (IRM).
DHowett-MSFT commentedon Jul 20, 2019
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.
[-]Example odd shell command line editing display vs. actual command[/-][+]Add support for VT102 Insertion-Replace Mode (IRM)[/+]egmontkob commentedon Oct 28, 2019
Yet another symptom of the same bug:
Resize the window to 63 columns. Start
mc(Midnight Commander) on Ubuntu, compiled against the S-Lang screen drawing library (as it's done in Ubuntu).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
<space>9Pu~Dn, reaching all the way to the very end.Actual:
<space>9Pu~Dis printed with the expected colors, and the last column remains empty, showing the terminal's background color.What the S-Lang library does is an ancient and obsolete hack for some terminals that don't have "pending wrap" (James Holderness (@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 (
nin this case) in the penultimate (62nd) column, and then using IRM, prints the penultimate letter (D) again in the penultimate (62nd) column, expecting it to push the previously printednto the 63rd.Even at bigger window sizes, such as the normal 80 columns,
mcmisses to paint the bottom right corner using some of its skins, e.g. F9 -> Options -> Appearance -> sand256 is one of these. For some mysterious reason, S-Lang decides to use different drawing method depending on some property of the skin. In this case, it repeats the aforementioned trick with space characters, whereas with most other themes, it just emits the escape sequence that wipes to the end.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
mccompiled against ncurses, apparently it knows about "pending wrap" and knows that this hack is not necessary.j4james commentedon Oct 29, 2019
I know DOS and the original Windows shell didn't support "pending wrap", but then they wouldn't have supported
IRMmode either. However, it wouldn't surprise me if there were other third-party terminal emulators for Windows that shared that wrapping behaviour, but were still able to handleIRM, so maybe that's the sort of thing that S-Lang is targetting.By the way,
IRMis on my TODO list (assuming nobody else takes it on first). It's just that we don't yet have a handler for ANSI modes, and the existing dispatch mechanism makes that a bit of a pain to add, so that was something I was hoping to address first. There are various other issues related to parameter handling (e.g. #2101 and possibly #942), and I wanted to make sure we had something that could satisfy all of those requirements if possible, so it's probably not going to be a quick fix.34 remaining items
vixie commentedon Dec 12, 2022
Anutrix commentedon Dec 12, 2022
vixie commentedon Dec 12, 2022
Anutrix commentedon Dec 12, 2022
dmiller423 commentedon Dec 24, 2022
This is still open 3&&1/2yrs later?
Leonard Hecker (@lhecker) I see you've been assigned this 2weeks ago, is it actually something in progress finally?
zaphod77 commentedon Dec 24, 2022
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.
lhecker commentedon Dec 25, 2022
I've recently removed
UnicodeStorage, however it doesn't actually make my implementation all that much more trivial. This is because my more important and more long term goal is to fully support Unicode (and extended grapheme clusters in turn) for conhost and Windows Terminal. Implementing IRM requires an "text insertion" primitive which may be implemented based on our existing code base, however this would build up on our existing non-Unicode support, which I'm really hesitant to do. I'd basically be writing code that I'm actively trying to remove. This is why I'm trading a bit longer development time for IRM, to write those new Unicode-supporting primitives that we will need in other areas as well, with a better integration into our long term vision.That said, I've already begun working on this. :)
I'm hoping to finish it before the 1.17 release ships, but it's possible I might miss it due to (unrelated) personal circumstances. In either case however I'm confident to finish it within January.
Add support for IRM (Insert Replace Mode) (#14700)
vixie commentedon Jan 28, 2023
works! tyvm.