Hi!
Short:
Editing commands sometimes don't (seem to) work on the first shell
prompt in newly opened xterm window:
$ bar^A^E^Afoo <ENTER>
foo bar
ksh: foo: not found
Long:
Every now and then when I open up a new xterm window, the initial row I
edit misbehaves in that it seemingly does not react to the line editing
commands. E.g. if I forgot to prepend 'sudo ' to the disklabel command
and decided to do it later, this could happen:
alexander@berk:~>disklabel -e^Asudo
sudo disklabel -e
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
...
I am far from a tty expert, but I would guess the tty is working in some
kind of line input mode rather than sending each single keypress one at
a time.
This has been a mild annoyance for quite some time now, but IIRC these
two changes, which may affect this, happened around that time:
1. tedu@ (again, IIRC) made a change to ksh that caused the window
geometry being refreshed for each new input line.
2. I switched to scrotwm (later spectrwm). I now run i3, which may or
may not share the bug, if there is one.
I just got an idea and issued 'stty -a' for a 'normal' terminal and a
misbehaving one and noticed them having 'pendin' and '-pendin',
respectively. I don't know if that's a clue or just a consequence of
something related.
I also noticed that a misbehaving terminal seems to recover (get its
normal editing behaviour back), even if I still have not left the first
line, if I open another terminal window. I am suspecting this could be
related to some resize-info message of sorts.
FWIW, I run with the following in ~/.Xresources:
xterm.*.charClass: 33:48,37:48,45-47:48,38:48
xterm.*.metaSendsEscape: true
xterm.*.VT100.geometry: 120x40
xterm.*.loginShell: true
xterm.*.scrollBar: false
xterm.*.saveLines: 20000
xterm.*.termName: xterm-color
xterm.*.visualBell: true
xterm.*.pointerMode: 1
/Alexander
