Dear rxvt-unicode list,
I'd like to ask about something that may or may not be a bug in
rxvt-unicode, namely what happens when the cursor is in the last
column of a line and a character has been written in that last column
so the terminal would wrap on the next character and a backspace is
written.
As you all know, if you output a character to the last column of the
terminal, the cursor does not wrap to the beginning of the next line
immediately, but stays at the end of that line, but a special flag is
set so that when the next character is written it goes to the
beginning of the next line instead of where the cursor is. (Search
for "Screen_WrapNext" in rxvt-unicode-9.06/src/screen.C if you want to
see how this is implemented.) Now when the terminal is in this state
and a backspace character is output, the cursor is moved to the last
but one column of the line, so it's actually not on the character
you've last written like it normally would be when you send a
backspace. This so far agrees with other terminals, including linux
console and (at least some) xterm.
The difference from other terminals is that in urxvt, backspace wraps
to the end of the previous line if you output it when the cursor is at
the beginning of a line. (This happens whether or not the previous
line is logically continued.) This means that if you type multiple
backspaces in a continued line, the cursor usually gets into the right
position as if the whole logical line was in one long screen line.
However, because of the above mentioned behavior, if you start
entering backspaces from an about-to-wrap state, the cursor goes to
one character before where it would be on a long line.
Where this gets much worse is when the last character in a line are
erased with backspace-space-backspace combination. This is exactly
what the terminal layer (stty or tcsetattr) does (on Linux at least,
but likely on other systems as well) if you erase a character with the
usual settings (ICANON and ECHOE set) by inputting the erase character
('\x7f' or '\x08' depending on the settings; or similarly when you
erase the whole line with the kill character). The consequence is
that if you're entering a line in canonical mode and erase multiple
characters past a line wrap (or kill a whole line that spans multiple
screen lines), the cursor gets into the wrong position and junk
characters remain in the last but one columns of lines. At first
hearing, this might not seem worse than what happens on a usual
terminal (eg. linux console or xterm) when you do the same -- there
erasing characters before a line wrap does not show up in any way.
Actually it's worse in two ways: firstly if you kill the whole logical
line the cursor ends up in the previous line (or even before that) and
can overwrite things there; secondly even if you just erase a few
characters past the line wrap, one more character is deleted on the
screen than what's actually deleted from the buffer, which is
confusing.
Now I'm not quite sure if this is a bug in urxvt or something else and
how it should be fixed, but here are my thoughts.
Firstly, the terminal layer of Linux is very ancient and is stable and
rarely changed, much more so than urxvt; and even if it's buggy it
would be very hard to change it on every machine (including those
where urxvt is not installed). (I have not tested other unix-like
operating systems so I've no idea if they use the same characters for
erasing, sorry.) Secondly, the terminal layer should work with as
many strange terminal as possible, and you don't get much more
portable than backspace-space-backspace (unless you count the kernel
default setting stty -ECHOE -ECHOK, which is useful for hardcopy
terminals and outputs the erased characters between a slash and a
backslash).
On the other hand, I'm not sure how this behavior can be fixed without
breaking everything else. Just changing backspace to just clear the
about-to-wrap flag when it's pressed in about-to-wrap state might
work, but as I've said, the current behavior is followed by other
terminal emulators as well, and so changing it might break any
program. (As always, if you change the terminfo data or patch ncurses
and the other screen libraries, you can't trust these changes to get
applied on all machines from where terminal output somehow goes to
urxvt.) As far as I know, programs don't know that backspace can jump
to the previous line, but they might as well know (or assume) what
happens if they backspace from an about-to-wrap position.
Summarized, I've no idea what the fix should be. It might be what I
mentioned above, or it might involve checking for logically continued
lines, or it might be that the only safe fix is completely disabling
backspacing over a line wrap etc. If you have a good guess, I may try
to write the patch and test, but I can't promise anything. (Given how
the modified gnu readline library built in bash which is the
terminal-handling code I use the most frequently has aquired really
serious screen update bugs in bash 4.0 which affect both urxvt and
other terminals, the terminal library in the joe editor historically
not handling the last screen column of the terminal well, and how
these two are the terminal applications I use the most, I probably
won't be too useful even in testing a patch.)
Thank you for any feedback in advance.
In case any of this matters, I used to use rxvt-unicode version 9.05
compiled from vanilla source and just updated to version 9.06. This
is on a linux-amd64 with the base system being debian lenny, with the
kernel being vanilla linux-2.6.30.1 from source, debian's xorg, and
vanilla gcc 4.3.3. Here are the configuration options I just compiled
the new version of urxvt with, the set of configuration options I used
to compile the one I used for longer are sadly lost.
--prefix=/usr/local --enable-xft --enable-font-styles
--disable-afterimage --disable-transparency --disable-fading
--disable-next-scroll --enable-frills --enable-iso14755
--enable-selectionscrolling --enable-mousewheel --enable-smart-resize
--enable-pointer-blank --enable-perl --enable-warnings
And here are the usual set of command line I use to start urxvt. The
encoding varies between iso-8859-2 and utf-8, and the window size
varies as well.
-ls -geometry 80x25 +sb -b 0 -bg \#000000 -fg \#c0c0c0 --colorBD
\#ffffff --color0 \#000000 --color1 \#aa0000 --color2 \#00aa00
--color3 \#aa5500 --color4 \#0000ff --color5 \#aa00aa --color6
\#00aaaa --color7 \#c0c0c0 --color8 \#555555 --color9 \#ff5555
--color10 \#55ff55 --color11 \#ffff55 --color12 \#5588ff --color13
\#ff55ff --color14 \#55ffff --color15 \#ffffff -cr \#c0f0a0 -fn
"x:-*-fecupboard-medium-r-*-*-20-*-*-*-*-*-iso10646-1,x:-*-terminus-bold-r-*-*-20-*-*-*-*-*-iso10646-1"
--boldFont "" -vb -sbg --print-pipe false --pointerBlank
--pointerBlankDelay 2147483647 -pe -searchable-scrollback,-readline
++iso14755_52
Ambrus
_______________________________________________
rxvt-unicode mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/rxvt-unicode
