Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 2 December 2011 00:16, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Reuben Thomas wrote:
>
>> I don't actually use Debian at present; I use Ubuntu. That may limit
>> my usefulness. However, at the very least, I'd be happy to try doing
>> this:
>
> Thanks. Unless the Ubuntu maintainers want to make this change as a
> differentiating feature instead of pushing it in Debian (and I can't
> see the point to that), I think you are still affected by what happens
> in Debian anyway.
Of course, and that is why I filed the bug in Debian. The point I'm
making is that I've tested Ubuntu packages on an Ubuntu oneiric
system, not Debian packages on a Debian system.
Here are the results of my tests:
Xterm & friends:
xterm: true (eightBitInput resource)
kterm: true (eightBitInput resource)
mlterm: true (--meta=esc command line option)
xvt: true (-7 command line option)
GNUStep (I imagine that GNUStep standards mean you wouldn't want to
change the default):
terminal.app: true (no option, but can remap keys)
rxvt & friends:
rxvt: false (meta8 resource)
rxvt-unicode: false (meta8 resource)
mrxvt: false (-m8/+m8 command line option)
wterm: false (-meta8 command line option)
aterm: false (-meta8 command line option)
libvte-based emulators (for at least some of these may need to select
preference “Keyboard→Disable other menu shortcut keys”, otherwise
Alt+some letters opens menu; again, this default probably shouldn't
change):
gnome-terminal: false (no option)
evilvte: false (no option)
guake: false (no option)
lxterminal: false (no option)
roxterm: false (no option)
sakura: false (no option)
terminator: false (no option)
vala-terminal: false (no option)
xfce4-terminal: false (no option)
konsole: false (no option)
Others:
eterm: false (--meta8 command line option)
pterm: false (no option)
In other words, only xterm, kterm, mlterm and xvt would require a
patch, and in all cases it would be simply to reverse an existing
default setting.
--
http://rrt.sc3d.org
Reply to: