Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Thu, Dec 08, 2011 at 11:59:46AM +0200, Riku Saikkonen wrote: > Reuben Thomas writes: > >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. > > There are a few more terminals to add to your list of Meta-key > behaviors: the text consoles of the kernels supported by Debian. > > Linux text console: false unimplemented (as are most of the cases mentioned) man terminfo(5): If the terminal has a ``meta key'' which acts as a shift key, setting the 8th bit of any character transmitted, this fact can be indicated with km. Otherwise, software will assume that the 8th bit is parity and it will usually be cleared. If strings exist to turn this ``meta mode'' on and off, they can be given as smm and rmm. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Reuben Thomas writes: >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. There are a few more terminals to add to your list of Meta-key behaviors: the text consoles of the kernels supported by Debian. Linux text console: false (That is, by default Alt+w sends ^[w and not the DIVISION SIGN character, at least on my i386 system. This appears to be changeable via setmetamode(1), which uses the KDSKBMETA ioctl documented in console_ioctl(4). I did not find the smm or rmm terminfo entries for linux, nor code that would implement such escape sequences to change the meta mode. I think the default is set in #define KBD_DEFMODE in linux/drivers/char/keyboard.c (search in the file for the two occurrences of "VC_META").) I don't have a Debian GNU/kFreeBSD system to test on, nor Debian GNU/Hurd. Maybe someone else could test those for completeness? -- -=- Rjs -=- r...@cs.hut.fi, riku.saikko...@hut.fi -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r50f2xkd@lambda.cs.hut.fi
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Reuben Thomas wrote: > On 4 December 2011 17:55, Jonathan Nieder wrote: >> Sounds sensible to me. I think the first step is to file a bug >> against debian-policy with X-Debbugs-Cc pointing to the relevant >> maintainers, so the new Right Thing To Do™ can be documented to avoid >> future regressions. > > Could you possibly file that bug? Filed: http://bugs.debian.org/651035 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111205080338.ge6...@elie.hsd1.il.comcast.net
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 4 December 2011 17:55, Jonathan Nieder wrote: > Reuben Thomas wrote: > >> For xterm, kterm and xvt, the simplest thing to do would seem to be to >> add a suitable default resource to the various /etc/X11/app-defaults >> files. (xvt doesn't install such a file, but since it respects >> resources it presumably could.) >> >> For mlterm a simple patch to reverse the default would be required. >> >> How does this sound? > > Sounds sensible to me. I think the first step is to file a bug > against debian-policy with X-Debbugs-Cc pointing to the relevant > maintainers, so the new Right Thing To Do™ can be documented to avoid > future regressions. Could you possibly file that bug? I'm abroad for a week, and don't really have the mental space to do something delicate like that which I've never done before. I think the advice is simple enough: add an eightBitInput: true resource to each term's default resources file, plus a default-negating patch to mlterm. -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOnWdoij_K6G86k6q7PhGXFGGLzx=mj-ucdobzjb1m_ixg0...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Reuben Thomas wrote: > For xterm, kterm and xvt, the simplest thing to do would seem to be to > add a suitable default resource to the various /etc/X11/app-defaults > files. (xvt doesn't install such a file, but since it respects > resources it presumably could.) > > For mlterm a simple patch to reverse the default would be required. > > How does this sound? Sounds sensible to me. I think the first step is to file a bug against debian-policy with X-Debbugs-Cc pointing to the relevant maintainers, so the new Right Thing To Do™ can be documented to avoid future regressions. It feels awkward to give advice like this without doing anything myself. Please don't take it as authoritative --- what the people actually working on these packages are happy with is more important. Many thanks, Jonathan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111204165504.ga3...@elie.hsd1.il.comcast.net
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 1 December 2011 22:58, Jonathan Nieder wrote: > 2. Proposing a patch for xterm bug#326200. For xterm, kterm and xvt, the simplest thing to do would seem to be to add a suitable default resource to the various /etc/X11/app-defaults files. (xvt doesn't install such a file, but since it respects resources it presumably could.) For mlterm a simple patch to reverse the default would be required. How does this sound? -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOnWdogVKAJCghn-UjY_jzAqZAg3+Ob7Vxry_RmWRS24=uu...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 2 December 2011 00:16, Jonathan Nieder 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 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caonwdogcdg16az9ms2o1coegddr_r_-eztbzuby3d4jtl09...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
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. [...] > Basic use of > apt-cache search and grep suggests the following: Yep, that seems like a sensible list. > I'd be quite happy to whip through that lot and see what the defaults are. Great. It might even be possible to automate that with some ncurses magic, but don't ask me how. :) -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111201231655.ge6...@elie.hsd1.il.comcast.net
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 1 December 2011 22:58, Jonathan Nieder wrote: > Hi again, > > Riku Saikkonen wrote: > >> I suppose this clearly is not something that should be changed while >> in a freeze, especially since xterm in Debian has had the current >> behaviour for so many years. But perhaps it would be possible to >> coordinate a consistent behaviour for all the terminals in the next >> Debian release after this frozen one? > > That sounded sensible to my innocent bystander ears. :) Reuben, would > you be willing to coordinate this (or do you know anyone who would be)? 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: > 1. Finding out what the major terminals in Debian currently do. If > xterm is not the odd man out, finding a consensus, for example by > reporting a bug against the debian-policy package with > X-Debbugs-Cc pointing to the relevant maintainers. What counts as "the major terminals"? Obviously xterm, uxterm, gnome-terminal, konsole, and which others? Should I use popcon to find out (how?)? Or can we draw up an arbitrary list? Basic use of apt-cache search and grep suggests the following: gnome-terminal xterm eterm evilvte guake kterm lxterminal mlterm mlterm-tiny mrxvt mrxvt-cjk mrxvt-mini pterm roxterm rxvt rxvt-beta rxvt-ml rxvt-unicode rxvt-unicode-256color rxvt-unicode-lite sakura terminal.app terminator vala-terminal wterm wterm-ml xfce4-terminal xvt konsole I'd be quite happy to whip through that lot and see what the defaults are. -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caonwdogmmvz-7ve1fs3r05yfqrozzypxb8x1dzpctg_hozp...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Hi again, Riku Saikkonen wrote: > I suppose this clearly is not something that should be changed while > in a freeze, especially since xterm in Debian has had the current > behaviour for so many years. But perhaps it would be possible to > coordinate a consistent behaviour for all the terminals in the next > Debian release after this frozen one? That sounded sensible to my innocent bystander ears. :) Reuben, would you be willing to coordinate this (or do you know anyone who would be)? That means: 1. Finding out what the major terminals in Debian currently do. If xterm is not the odd man out, finding a consensus, for example by reporting a bug against the debian-policy package with X-Debbugs-Cc pointing to the relevant maintainers. 2. Proposing a patch for xterm bug#326200. 3. Proposing a patch for bash bug#574396. 4. Being ready to help people respond to bugs that arise from the above. If one wants to make this change and find relevant bugs in time for wheezy, now's probably the time. Thanks and hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111201215822.ga5...@elie.hsd1.il.comcast.net
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
(I'm just a long-time xterm user who follows the Debian bug reports every now and then...) Reuben Thomas writes: >On 6 November 2010 17:00, Thomas Dickey wrote: [about "*eightBitInput: true" being the default] >> It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered >> without dead-keys, etc. >Under what conditions? If I set my keyboard to Greek, for example, so >that I'm entering only non-ASCII characters with most keystrokes, >uxterm faithfully shows Greek characters (with eightBitInput: false). Here is a concrete example that I've been using for years, ever since I first learned it: If I type Alt-0, I get the DEGREE SIGN character '°'. However, if I run xterm -xrm '*eightBitInput: false' then Alt-0 gives me ^[0 (i.e. ESC + 0) instead. Same with, e.g., Alt-7 to get the MIDDLE DOT '·' or Alt-w to get the DIVISION SIGN '÷' or Alt-Shift-w to get the MULTIPLICATION SIGN '×'. I can of course (as I learned later) get the degree sign character also using "Compose ^ 0" (presuming that I have a Compose key configured and, of course, that I know about this). But Alt-0 is quicker to type and (it seems to me) easier to remember. Of course, the downside is that Alt-0 in Emacs gives the ° character instead of the Emacs command M-0 (e.g., Alt-7 * gives me either '***' or '·*' depending on the eightBitInput setting). In Emacs running in its own X window (instead of under xterm): Alt-7 * gives '***' which would suggest using *eightBitInput: false to be consistent. However, it is not really completely consistent using either value of eightBitInput: C-q Alt-7 gives '·' in Emacs running under an X window C-q Alt-7 gives '·' in Emacs under xterm with *eightBitInput: true C-q Alt-7 gives '^[*' in Emacs under xterm with *eightBitInput: false So the behaviour of C-q Alt-7 would suggest *eightBitInput: true (especially since there are fewer ways of getting '·' with eightBitInput: false). I guess C-q Alt-7 giving '·' in an X window is a decision made by Emacs developers sometime in the past (in an Emacs X window, it is of course more useful to get '·' than '^[*' from this special command). So both *eightBitInput: false and *eightBitInput: true are useful in their own ways. This probably really is a user preference (for power users, at least), so I guess both *eightBitInput: true and *eightBitInput: false are going to annoy some users. However, I guess it would be useful for Debian to be consistent about this in all the terminals it ships (including the Linux and kFreeBSD text consoles as well as X terminal emulators). I'm personally not really sure which option I prefer: I'm used to the Debian default of *eightBitInput: true, and use it every now and then (as I described above), but it's also annoying that I have to use ESC in Emacs so much... Maybe *eightBitInput: false would be less surprising for new users of Emacs under xterm (since Alt-x would work as M-x, and not many people seem to know that, e.g., Alt-0 could be the degree sign). I suppose this clearly is not something that should be changed while in a freeze, especially since xterm in Debian has had the current behaviour for so many years. But perhaps it would be possible to coordinate a consistent behaviour for all the terminals in the next Debian release after this frozen one? -- -=- Rjs -=- r...@cs.hut.fi, riku.saikko...@hut.fi -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oca16ilx@lambda.cs.hut.fi
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Sun, 7 Nov 2010, Riku Saikkonen wrote: (I'm just a long-time xterm user who follows the Debian bug reports every now and then...) Reuben Thomas writes: On 6 November 2010 17:00, Thomas Dickey wrote: [about "*eightBitInput: true" being the default] It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered without dead-keys, etc. Under what conditions? If I set my keyboard to Greek, for example, so that I'm entering only non-ASCII characters with most keystrokes, uxterm faithfully shows Greek characters (with eightBitInput: false). Here is a concrete example that I've been using for years, ever since I first learned it: If I type Alt-0, I get the DEGREE SIGN character '°'. However, if I run xterm -xrm '*eightBitInput: false' then Alt-0 gives me ^[0 (i.e. ESC + 0) instead. Same with, e.g., Alt-7 to get the MIDDLE DOT '·' or Alt-w to get the DIVISION SIGN '÷' or Alt-Shift-w to get the MULTIPLICATION SIGN '×'. I can of course (as I learned later) get the degree sign character also using "Compose ^ 0" (presuming that I have a Compose key configured and, of course, that I know about this). But Alt-0 is quicker to type and (it seems to me) easier to remember. Of course, the downside is that Alt-0 in Emacs gives the ° character instead of the Emacs command M-0 (e.g., Alt-7 * gives me either '***' or '·*' depending on the eightBitInput setting). In Emacs running in its own X window (instead of under xterm): Alt-7 * gives '***' which would suggest using *eightBitInput: false to be consistent. However, it is not really completely consistent using either value of eightBitInput: C-q Alt-7 gives '·' in Emacs running under an X window C-q Alt-7 gives '·' in Emacs under xterm with *eightBitInput: true C-q Alt-7 gives '^[*' in Emacs under xterm with *eightBitInput: false So the behaviour of C-q Alt-7 would suggest *eightBitInput: true (especially since there are fewer ways of getting '·' with eightBitInput: false). I guess C-q Alt-7 giving '·' in an X window is a decision made by Emacs developers sometime in the past (in an Emacs X window, it is of course more useful to get '·' than '^[*' from this special command). So both *eightBitInput: false and *eightBitInput: true are useful in their own ways. This probably really is a user preference (for power users, at least), so I guess both *eightBitInput: true and *eightBitInput: false are going to annoy some users. However, I guess it would be useful for Debian to be consistent about this in all the terminals it ships (including the Linux and kFreeBSD text consoles as well as X terminal emulators). I'm personally not really sure which option I prefer: I'm used to the Debian default of *eightBitInput: true, and use it every now and then (as I described above), but it's also annoying that I have to use ESC in Emacs so much... Maybe *eightBitInput: false would be less surprising for new users of Emacs under xterm (since Alt-x would work as M-x, and not many people seem to know that, e.g., Alt-0 could be the degree sign). yes - but Similarly - I use the backarrow-key menu entry often, since Linux happens to be the only platform using DEL rather than BS. I suppose this clearly is not something that should be changed while in a freeze, especially since xterm in Debian has had the current behaviour for so many years. But perhaps it would be possible to coordinate a consistent behaviour for all the terminals in the next Debian release after this frozen one? It's really up to Debian to decide what they want to do in their packages, and why. xterm's the only terminal mentioned which actually _implements_ meta mode, which seems to be confused with sending escape characters. Since sending escape characters seems to be the only validly-expressed goal, that's done better by the metaSendsEscape resource. I made that a menu entry, so it could be changed back and forth. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Sun, 7 Nov 2010, Reuben Thomas wrote:
On 7 November 2010 16:52, Thomas Dickey wrote:
On Sun, 7 Nov 2010, Reuben Thomas wrote:
On 6 November 2010 17:00, Thomas Dickey wrote:
It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered
without dead-keys, etc.
Under what conditions? If I set my keyboard to Greek, for example, so
that I'm entering only non-ASCII characters with most keystrokes,
uxterm faithfully shows Greek characters (with eightBitInput: false).
Sorry if I'm being obtuse, but I'd like to home in at the very least
on an extremely clear explanation for the docs.
It's in the manpage (though not pointing out explicitly that the conversion
is done at a point where it's useful for UTF-8).
Sorry, I must be being stupid, but can you please be explicit? I am
I was referring to this paragraph, above:
eightBitInput (class EightBitInput)
If "true", Meta characters (a single-byte character combined
with the Meta modifier key) input from the keyboard are pre-
sented as a single character with the eighth bit turned on.
The terminal is put into 8-bit mode. If "false", Meta charac-
ters are converted into a two-character sequence with the char-
acter itself preceded by ESC. On startup, xterm tries to put
the terminal into 7-bit mode. The metaSendsEscape and altSend-
sEscape resources may override this. The default is "true."
which in context refers to this chunk of code in input.c
if (eightbit && (kd.nbytes == 1) && screen->input_eight_bits) {
IChar ch = CharOf(kd.strbuf[0]);
if (ch < 128) {
kd.strbuf[0] |= (char) 0x80;
TRACE(("...input shift from %d to %d (%#x to %#x)\n",
ch, CharOf(kd.strbuf[0]),
ch, CharOf(kd.strbuf[0])));
#if OPT_WIDE_CHARS
if (screen->utf8_mode) {
/*
* We could interpret the incoming code as "in the
* current locale", but it's simpler to treat it as
* a Unicode value to translate to UTF-8.
*/
ch = CharOf(kd.strbuf[0]);
kd.nbytes = 2;
kd.strbuf[0] = (char) (0xc0 | ((ch >> 6) & 0x3));
kd.strbuf[1] = (char) (0x80 | (ch & 0x3f));
TRACE(("...encoded %#x in UTF-8 as %#x,%#x\n",
ch, CharOf(kd.strbuf[0]), CharOf(kd.strbuf[1])));
}
#endif
}
eightbit = False;
}
trying to answer the question: "when is having eightBitInput: false a
problem?". You answered "[when you want to get] ISO-8859-1 (or
equivalents in UTF-8) entered without dead-keys, etc.". But when I
have eightBitInput: false, I can quite happily enter non-ASCII
characters (i.e. "ISO-8859-1 (or equivalents in UTF-8)").
I have tried reading the man page again, and I can't find anything
that sheds light on this question.
So, once more: under what conditions does setting eightBitInput: false
prevent the straightforward input of non-ASCII characters?
I suppose as long as the only users you're considering are using gnome or
KDE, then that's true. (There's nothing for setting keyboard here, using
fvwm).
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101107124705.y66...@mail101.his.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 7 November 2010 16:52, Thomas Dickey wrote: > On Sun, 7 Nov 2010, Reuben Thomas wrote: > >> On 6 November 2010 17:00, Thomas Dickey wrote: >>> >>> It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered >>> without dead-keys, etc. >> >> Under what conditions? If I set my keyboard to Greek, for example, so >> that I'm entering only non-ASCII characters with most keystrokes, >> uxterm faithfully shows Greek characters (with eightBitInput: false). >> Sorry if I'm being obtuse, but I'd like to home in at the very least >> on an extremely clear explanation for the docs. > > It's in the manpage (though not pointing out explicitly that the conversion > is done at a point where it's useful for UTF-8). Sorry, I must be being stupid, but can you please be explicit? I am trying to answer the question: "when is having eightBitInput: false a problem?". You answered "[when you want to get] ISO-8859-1 (or equivalents in UTF-8) entered without dead-keys, etc.". But when I have eightBitInput: false, I can quite happily enter non-ASCII characters (i.e. "ISO-8859-1 (or equivalents in UTF-8)"). I have tried reading the man page again, and I can't find anything that sheds light on this question. So, once more: under what conditions does setting eightBitInput: false prevent the straightforward input of non-ASCII characters? -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinfogj2+uggmghavvdg_vkfco20pi1tger_g...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Sun, 7 Nov 2010, Reuben Thomas wrote: On 6 November 2010 17:00, Thomas Dickey wrote: On Sat, 6 Nov 2010, Reuben Thomas wrote: Why do some users want it the other way? I'm still looking for a reason (other than the one than Jonathan quoted about bash, which It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered without dead-keys, etc. Under what conditions? If I set my keyboard to Greek, for example, so that I'm entering only non-ASCII characters with most keystrokes, uxterm faithfully shows Greek characters (with eightBitInput: false). Sorry if I'm being obtuse, but I'd like to home in at the very least on an extremely clear explanation for the docs. It's in the manpage (though not pointing out explicitly that the conversion is done at a point where it's useful for UTF-8). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101107115034.d66...@mail101.his.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 6 November 2010 17:00, Thomas Dickey wrote: > On Sat, 6 Nov 2010, Reuben Thomas wrote: > >> Why do some users want it the other way? I'm still looking for a >> reason (other than the one than Jonathan quoted about bash, which > > It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered > without dead-keys, etc. Under what conditions? If I set my keyboard to Greek, for example, so that I'm entering only non-ASCII characters with most keystrokes, uxterm faithfully shows Greek characters (with eightBitInput: false). Sorry if I'm being obtuse, but I'd like to home in at the very least on an extremely clear explanation for the docs. -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=kqspdjsu1fdb29skzhfhtamomgh73yqqlv...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Sun, 7 Nov 2010, Reuben Thomas wrote: On 6 November 2010 17:14, Thomas Dickey wrote: On Sat, 6 Nov 2010, Reuben Thomas wrote: users be able to understand which setting they are likely to want, but also stop complaining about the default (as I am doing!). I'm also interested to know why this is the default in xterm, but not in gnome-terminal, konsole or unicode-rxvt. Is it the default in any other modern terminal? None of those are "modern" in the sense that you'd like to imply. I think that was a bad choice of word. By "modern", I meant "actively maintained at present". In that case, gnome-terminal is debatable (it's being changed, but not maintained except in the loosest sense of the term). In either case, gnome-terminal and konsole haven't changed that part of the design for a decade. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101107114539.d66...@mail101.his.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 6 November 2010 17:14, Thomas Dickey wrote: > On Sat, 6 Nov 2010, Reuben Thomas wrote: > >> users be able to understand which setting they are likely to want, but >> also stop complaining about the default (as I am doing!). I'm also >> interested to know why this is the default in xterm, but not in >> gnome-terminal, konsole or unicode-rxvt. Is it the default in any >> other modern terminal? > > None of those are "modern" in the sense that you'd like to imply. I think that was a bad choice of word. By "modern", I meant "actively maintained at present". -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimpd2+chxbc6y3o+iq0hsfxefrv6tgb3_+rk...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Sat, 6 Nov 2010, Reuben Thomas wrote: users be able to understand which setting they are likely to want, but also stop complaining about the default (as I am doing!). I'm also interested to know why this is the default in xterm, but not in gnome-terminal, konsole or unicode-rxvt. Is it the default in any other modern terminal? None of those are "modern" in the sense that you'd like to imply. In each case, the design dates back at least ten years (longer in the case of rxvt-unicode, which uses the convention from rxvt in the mid 1990s). Likewise, the "modern" issue we're discussing is emacs's use of a feature older than that. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101106131106.f14...@mail101.his.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Sat, 6 Nov 2010, Reuben Thomas wrote: Why do some users want it the other way? I'm still looking for a reason (other than the one than Jonathan quoted about bash, which It's a way of getting the ISO-8859-1 (or equivalents in UTF-8) entered without dead-keys, etc. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101106125816.h14...@mail101.his.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 5 November 2010 21:40, Thomas Dickey wrote: > On Fri, 5 Nov 2010, Jonathan Nieder wrote: > >> Reuben Thomas wrote: >> >>> What is wrong with patching xterm so that it defaults to eightBitInput >>> being false rather than true, as other terminals do? >> >> Nothing I can see except that we are in a freeze. It is probably >> worth making the change anyway, but I will leave that to the emacs >> users. >> >> Re interaction with metaSendsEscape: of course it would not confuse >> new users, but would existing configurations might start to misbehave? > > probably. It's configurable at runtime (menu and escape sequence) because > this is an area where half the users want it one way, the other half the > other way. Why do some users want it the other way? I'm still looking for a reason (other than the one than Jonathan quoted about bash, which seems to have things the wrong way round). This is precisely the sort of thing that would be good to add to some documentation so that it's obvious that both ways have pros and cons, and hence, not only will users be able to understand which setting they are likely to want, but also stop complaining about the default (as I am doing!). I'm also interested to know why this is the default in xterm, but not in gnome-terminal, konsole or unicode-rxvt. Is it the default in any other modern terminal? -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim_nhv+35m3g-e+9w1aezhcuv8xsxivgecdz...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On Fri, 5 Nov 2010, Jonathan Nieder wrote: Reuben Thomas wrote: What is wrong with patching xterm so that it defaults to eightBitInput being false rather than true, as other terminals do? Nothing I can see except that we are in a freeze. It is probably worth making the change anyway, but I will leave that to the emacs users. Re interaction with metaSendsEscape: of course it would not confuse new users, but would existing configurations might start to misbehave? probably. It's configurable at runtime (menu and escape sequence) because this is an area where half the users want it one way, the other half the other way. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101105173702.r76...@mail101.his.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Reuben Thomas wrote: > What is wrong with patching xterm so that it defaults to eightBitInput > being false rather than true, as other terminals do? Nothing I can see except that we are in a freeze. It is probably worth making the change anyway, but I will leave that to the emacs users. Re interaction with metaSendsEscape: of course it would not confuse new users, but would existing configurations might start to misbehave? I readily admit I do not understand the details. Bug#574396 does not look resolved and I am too ignorant to figure out the current state of things. Thanks again for reporting this --- I had been wondering why Meta+key did not work in emacs. Jonathan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101105185705.ga2...@burratino
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 5 November 2010 18:30, Jonathan Nieder wrote: [Sorry for not understanding what you were after.] > Sven Joachim wrote: > > | Now after reading #574396 I see that with the xterm resources > | > | xterm*metaSendsEscape: false > | xterm*eightBitInput: false > | > | and bash as shell meta-key combinations yield non-ASCII characters, This I do not understand. "metaSendsEscape" defaults to false, and it is precisely to obtain ASCII characters (e.g. Meta-p is sent as ESC P) that one sets eightBitInput to false. With these two settings false, only 7-bit ASCII characters are sent! (Setting either metaSendsEscape to true or eightBitInput to false has the result that only 7-bit ASCII is sent.) > I guess we can rely on people to keep the default of metaSendsEscape? Well, if they don't, they will have read the docs. > Or perhaps a note in README.Debian would be needed to warn people. > If you know what to do, please provide a patch. :) Otherwise, thoughts > welcome. What is wrong with patching xterm so that it defaults to eightBitInput being false rather than true, as other terminals do? I would like to see what Thomas Dickey thinks, in any case (Thomas, I hope you don't mind the Cc:; see http://bugs.debian.org/326200 for the rest of this thread.). -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=x283c34kxiriz+6gen4gbw+îkrobym-3...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Reuben Thomas wrote: > On 3 November 2010 04:52:29 UTC, Jonathan Nieder wrote: >> Could you give a pointer or elaborate on the ramifications (perhaps an >> example)? Mostly I am curious. > > xterm(1) has the details. Well, no, it doesn't. What I was looking for was: "emacs -nw" and similar apps do not recognize Meta+key without this setting. and: > I note that urxvt also > defaults to Meta+key sending an escape (it calls the resource "meta8", > and defaults to false). I have not come across any negative > ramifications (obviously, it is no longer possible to produce certain > characters with Meta, but there are better ways to produce most > non-ASCII printing characters). and: Sven Joachim wrote: | Now after reading #574396 I see that with the xterm resources | | xterm*metaSendsEscape: false | xterm*eightBitInput: false | | and bash as shell meta-key combinations yield non-ASCII characters, I guess we can rely on people to keep the default of metaSendsEscape? Or perhaps a note in README.Debian would be needed to warn people. If you know what to do, please provide a patch. :) Otherwise, thoughts welcome. Thanks. Jonathan -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101105183038.ga2...@burratino
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
On 3 November 2010 04:52:29 UTC, Jonathan Nieder wrote: > > Could you give a pointer or elaborate on the ramifications (perhaps an > example)? Mostly I am curious. xterm(1) has the details. > Probably in response to your request, at some point between xterm 204 > and 208 it learned an alt-sends-esc menu item to toggle this at will. I'd much rather have this as the default. I note that urxvt also defaults to Meta+key sending an escape (it calls the resource "meta8", and defaults to false). I have not come across any negative ramifications (obviously, it is no longer possible to produce certain characters with Meta, but there are better ways to produce most non-ASCII printing characters). -- http://rrt.sc3d.org -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin3yk6g8vgqeb4rviefvhce4xzqqk0+txa8g...@mail.gmail.com
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Hi, Reuben Thomas wrote: > Please set eightBitInput: false by default so that, as in konsole and > gnome-terminal, Alt+letter combinations work in, for example, bash, > out of the box. Could you give a pointer or elaborate on the ramifications (perhaps an example)? Mostly I am curious. Probably in response to your request, at some point between xterm 204 and 208 it learned an alt-sends-esc menu item to toggle this at will. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101103045229.ga10...@burratino
Bug#326200: xterm: please set eightBitInput: false by default so Alt is usable as such
Package: xterm Version: 4.3.0.dfsg.1-14 Severity: wishlist Please set eightBitInput: false by default so that, as in konsole and gnome-terminal, Alt+letter combinations work in, for example, bash, out of the box. (I hope this is the right place to attack this problem; I discussed it with Thomas Dickey at some length to clarify my understanding of what's going on.) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages xterm depends on: ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libexpat11.95.8-3XML parsing C library - runtime li ii libfontconfig1 2.3.1-2 generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libice6 4.3.0.dfsg.1-14 Inter-Client Exchange library ii libncurses5 5.4-9 Shared libraries for terminal hand ii libsm6 4.3.0.dfsg.1-14 X Window System Session Management ii libxaw7 4.3.0.dfsg.1-14 X Athena widget set library ii libxext6 4.3.0.dfsg.1-14 X Window System miscellaneous exte ii libxft2 2.1.7-1 FreeType-based font drawing librar ii libxmu6 4.3.0.dfsg.1-14 X Window System miscellaneous util ii libxpm4 4.3.0.dfsg.1-14 X pixmap library ii libxrender1 0.8.3-7 X Rendering Extension client libra ii libxt6 4.3.0.dfsg.1-14 X Toolkit Intrinsics ii xfree86-common 4.3.0.dfsg.1-14 X Window System (XFree86) infrastr ii xlibs4.3.0.dfsg.1-14 X Keyboard Extension (XKB) configu ii xlibs-data 4.3.0.dfsg.1-14 X Window System client data -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
