(I'm just a long-time xterm user who follows the Debian bug reports every now and then...)
Reuben Thomas <[email protected]> writes: >On 6 November 2010 17:00, Thomas Dickey <[email protected]> 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 -=- [email protected], [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
