Bug 8980
| Summary: | XTerm appdefaults contains broken keybindings | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Hans de Goede <hdegoede> | ||||
| Component: | XFree86 | Assignee: | Preston Brown <pbrown> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 6.2 | ||||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2000-02-24 02:21:19 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Hans de Goede
2000-01-30 13:46:31 UTC
Created attachment 82 [details]
Patch which adds a missing \n\
Please also add the following 4 lines to the XTerm appdefaults,
changing the F1-F4 esc sequences from VT100 to VT220, as they used to be with
3.2 and as a lott of apps expect. As discussed by email with bero, pbrown and
timp.
<Key>F1: string(0x1b) string("[11~") \n\
<Key>F2: string(0x1b) string("[12~") \n\
<Key>F3: string(0x1b) string("[13~") \n\
<Key>F4: string(0x1b) string("[14~") \n\
These should be added under the Shifted F-keys bindings !
In case you want to restore my mousewheel bindings to, and to make once again
very clear that these should go under the shifted F-keys, here's my complete
list:
! keyboard bindings for Xterm in VT100 mode
XTerm.VT100.translations: #override \
Shift <Key>F1: string(0x1b) string("[23~") \n\
Shift <Key>F2: string(0x1b) string("[24~") \n\
Shift <Key>F3: string(0x1b) string("[25~") \n\
Shift <Key>F4: string(0x1b) string("[26~") \n\
Shift <Key>F5: string(0x1b) string("[28~") \n\
Shift <Key>F6: string(0x1b) string("[29~") \n\
Shift <Key>F7: string(0x1b) string("[31~") \n\
Shift <Key>F8: string(0x1b) string("[32~") \n\
Shift <Key>F9: string(0x1b) string("[33~") \n\
Shift <Key>F10: string(0x1b) string("[34~") \n\
<Key>F1: string(0x1b) string("[11~") \n\
<Key>F2: string(0x1b) string("[12~") \n\
<Key>F3: string(0x1b) string("[13~") \n\
<Key>F4: string(0x1b) string("[14~") \n\
<Key>Delete: string(0x1b) string("[3~") \n\
Ctrl <Key>Home: string(0x1b) string("[1~") \n\
Ctrl <Key>End: string(0x1b) string("[4~") \n\
<Key>Home: string(0x1b) string("OH") \n\
<Key>End: string(0x1b) string("OF") \n\
~@Num_Lock <Key>KP_Delete: string(0x1b) string("[3~") \n\
~@Num_Lock Ctrl <Key>KP_Home: string(0x1b) string("[1~") \n\
~@Num_Lock Ctrl <Key>KP_End: string(0x1b) string("[4~") \n\
~@Num_Lock <Key>KP_Home: string(0x1b) string("OH") \n\
~@Num_Lock <Key>KP_End: string(0x1b) string("OF") \n\
Ctrl <Key>Return: string(0x1b) string(0x0D) \n\
~@Num_Lock Ctrl <Key>KP_Enter: string(0x1b) string(0x0D) \n\
Ctrl <Key>Tab: string(0x1b) string(0x09) \n\
Alt Shift <Btn4Down>: string(0x1b) string("[5~") \n\
Alt Shift <Btn5Down>: string(0x1b) string("[6~") \n\
Alt Ctrl <Btn4Down>: string(0x1b) string("OA") \n\
Alt Ctrl <Btn5Down>: string(0x1b) string("OB") \n\
Alt <Btn4Down>: string(0x1b) string("OA") string(0x1b)
Alt <Btn5Down>: string(0x1b) string("OB") string(0x1b)
Shift <Btn4Down>: scroll-back(1,page) \n\
Shift <Btn5Down>: scroll-forw(1,page) \n\
Ctrl <Btn4Down>: scroll-back(1,line) \n\
Ctrl <Btn5Down>: scroll-forw(1,line) \n\
<Btn4Down>: scroll-back(5,line) \n\
<Btn5Down>: scroll-forw(5,line)
fixed, but not in time to make it into beta3. Will be in 6.2 final. It seems already fixed in beta3, but only the \n\ is added, not the VT220 esc-sequences for F1-F4 (fixing F1 in vim & ntsysv amongst others). Could you verify this? I did get this. verified. I just checked XF86-3.3.6-13 from rawhide, and it still misses the \n\ and doesn't include the F1-F4 bindings (only the shift F1-F4 bindings) are you _really_ sure this is fixed? Just checked the snapshot on ftp.beta.redhat.com and in XFree86-3.3.6-14, this
is still not fixed:
-The bindings for the shifted F keys (which do work in konsole, gnome-terminal,
Eterm & rxvt) and to make the F1-F4 key send the VT220 style esc-sequences
(needed for vim and ntsysv (as discussed before) are missing.
-The ~@Num_Lock is missing without it the keypad keys will send home, end or
del even with numlock enabled.
-The Alt <Btn4Down> / Alt <Btn5Down> bindings are truncated.
(my fault, so are they in the above list)
So the full binding list should be:
! keyboard bindings for Xterm in VT100 mode
XTerm.VT100.translations: #override \
Shift <Key>F1: string(0x1b) string("[23~") \n\
Shift <Key>F2: string(0x1b) string("[24~") \n\
Shift <Key>F3: string(0x1b) string("[25~") \n\
Shift <Key>F4: string(0x1b) string("[26~") \n\
Shift <Key>F5: string(0x1b) string("[28~") \n\
Shift <Key>F6: string(0x1b) string("[29~") \n\
Shift <Key>F7: string(0x1b) string("[31~") \n\
Shift <Key>F8: string(0x1b) string("[32~") \n\
Shift <Key>F9: string(0x1b) string("[33~") \n\
Shift <Key>F10: string(0x1b) string("[34~") \n\
<Key>F1: string(0x1b) string("[11~") \n\
<Key>F2: string(0x1b) string("[12~") \n\
<Key>F3: string(0x1b) string("[13~") \n\
<Key>F4: string(0x1b) string("[14~") \n\
<Key>Delete: string(0x1b) string("[3~") \n\
<Key>Home: string(0x1b) string("OH") \n\
<Key>End: string(0x1b) string("OF") \n\
~@Num_Lock <Key>KP_Delete: string(0x1b) string("[3~") \n\
~@Num_Lock <Key>KP_Home: string(0x1b) string("OH") \n\
~@Num_Lock <Key>KP_End: string(0x1b) string("OF") \n\
Alt Shift <Btn4Down>: string(0x1b) string("[5~") \n\
Alt Shift <Btn5Down>: string(0x1b) string("[6~") \n\
Alt Ctrl <Btn4Down>: string(0x1b) string("OA") \n\
Alt Ctrl <Btn5Down>: string(0x1b) string("OB") \n\
Alt <Btn4Down>: string(0x1b) string("OA") string(0x1b)
string("OA") string(0x1b) string("OA") string(0x1b) string("OA") string(0x1b)
string("OA") \n\
Alt <Btn5Down>: string(0x1b) string("OB") string(0x1b)
string("OB") string(0x1b) string("OB") string(0x1b) string("OB") string(0x1b)
string("OB") \n\
Shift <Btn4Down>: scroll-back(1,page) \n\
Shift <Btn5Down>: scroll-forw(1,page) \n\
Ctrl <Btn4Down>: scroll-back(1,line) \n\
Ctrl <Btn5Down>: scroll-forw(1,line) \n\
<Btn4Down>: scroll-back(5,line) \n\
<Btn5Down>: scroll-forw(5,line)
With the Alt <Btn4Down> / Alt <Btn5Down> lists unwrapped.
we are currently following the debian and xfree86 established keybindings by leaving F1-F4 as they are. However, I do note your problem with ntsysv (this is most likely a slang problem) and I am looking into it.) Terminfo and termcap all match now. I note that your home and end mappings are incorrect for terminfo and termcap. Our home and ends are all consistent with the linux console / stock terminfo now. the shifted fkeys are relevant, I am adding them now, as well as fixing the truncated button translations. I have no problem generating the standard number pad keys when numlock is on, so I am not adding these translations. The F1-F4 keys are open to debate, if we fix slang. I have modified the other terminals to send the standard xterm codes. Please give me definitive evidence why we should send the vt220 codes, as well as proof that all other apps (like emacs, etc.) don't break if we change it and terminfo/termcap. According to the Xterm FAQ, this is probably not a great idea. http://www.clark.net/pub/dickey/xterm/xterm.faq.html#how_do_i First of all, the ~@Num_Lock is really needed, it says that it has not-num-lock as modifier if you don't do this keypad 7 and 1 will send home and end with numlock on instead of 7 and 1. This _really_ is nescesarry. If you wish to follow the xfree86 xterm settings combined with the debian keyboard guidelines, that's fine by me. I don't mind as long as the problems are fixed, and thus as long as all terminals are consistent (and so are termcap / terminfo). Too bad, you didn't decide on this earlier this would have saved me a lott of work. The big difference between my solution, and the debian keyboard guidelines was that I tried to be as historical correct as possible. With the new bindigns, the xfree86 xterm, and other xterm emulators aren't compatible with the Xconsortium xterm (see the faq you quoted), and this could lead to trouble interacting with other unix variants. But as said, I don't mind and I respect your choices as long as they are done consistently. (Just to bad of the wast of time ;( ) I already took a quick look at your patches yesterday, and here are a few initial comments. I'll send you a mail with a full list of comments: -The rxvt binary is patched, but my previous patches used Xresources to fix the keybindings, these Xresources override the new default settings, thus rxvt still sends my keys, not the debian ones. Solution: remove /usr/X11R6/lib/app-defaults/Rxvt. The only thing it contains are my new keybindings. -With the ESC-O-F and ESC-O-H bindings for xterm goen you can remove them from /etc/inputrc -ntsysv & vim both have broken F1 -The "stty erase `tput kbs`" in /etc/bashrc, was mainly there to set the stty erase correct for xterm, since xterm's backspace now == console backspace this isn't needed anymore, it can still help people telnetting in from obscure terminals though. (Where backspace != console backspace) Hans: I was wrong about the num lock stuff, and you were right. Shoot me for thinking I was in an xterm when I was doing the testing (it was a konsole... :( ) I will add them immediately. I fixed newt last night to correctly work with the PF1-PF4 style function keys. It was broken. I appreciate all your work in this area, really I do. I'll fix rxvt resources right now too. And hans: no it wasn't a waste of time. You made us get up off our butts and realize that this problem really did need solving before 6.2 went out the door, and not after. Your numerous bug reports, suggestions, and patches were a very big motivator for Bero and Myself. I'm going to leave inputrc as is for people telnetting into new red hat boxes from older systems that may have this mapping. ntsysv is fixed with the new newt, which I tested. I don't seem to have any problems with the latest vim and F1 using the \E[OP keysym, but I'll check into it again. |