On Mon, May 05, 2008 at 01:29:58PM -0500, [EMAIL PROTECTED] wrote: > > > On Mon, 5 May 2008, Thomas Dickey wrote: > >> On Mon, 5 May 2008, Sergey Vlasov wrote: >> >>> On Sun, 4 May 2008 18:06:00 -0400 (EDT) Thomas Dickey wrote: >>> >>>> There is a control sequence in xterm which can change this mode, but >>>> I'd be surprised if mc is using it. >>> >>> Recent libreadline (used by bash) sends this - you can observe it with >>> 'strace -e write bash': >>> >>> write(2, "\33[?1034h", 8) = 8 >> >> I did recall that - hadn't related it to mc... >> >>> When xterm receives this sequence, it switches to "8-bit mode" >>> (*VT100.eightBitInput: true), where the Meta key sets the 0x80 bit of >>> input characters instead of adding the ESC prefix. The "konsole" >>> terminal emulator from KDE just ignores this sequence and continues to >>> send the ESC prefix for Meta. >> >> yes - konsole doesn't implement the meta feature with or without the >> control sequence. >> >>> Apparently this sequence comes from the 'smm' string in the terminfo >>> database, which was added somewhere between the 211 and 222 releases >>> of xterm (I do not see an explanation for this in xterm.log.html). >> >> It's in #216, added for completeness (since I'd added the control >> sequence at that point). I recall some discussion regarding readline, >> which turns on the feature if it exists (and commented that readline >> should have made it optional). >> >>> There does not seem to be a way to disable this behavior through the >>> libreadline config file (~/.inputrc). >>> >>> A possible workaround in ~/.Xresources: >>> >>> *VT100.altIsNotMeta: true >>> *VT100.altSendsEscape: true >>> *VT100.metaSendsEscape: true >>> *VT100.Translations: #override \ >>> Meta<KeyPress>: insert-seven-bit() >>> >>> Setting just metaSendsEscape: true is not enough in the common case >>> when Meta and Alt are the same key - apparently in this case xterm >>> treats this modifier key as Alt instead of Meta, even though the Meta >>> translations work for it; and the code in input.c:Input() does not >>> reset the "eightbit" flag in the alt_sends_esc case, like it does for >>> meta_sends_esc, therefore the translation override is needed to >>> prevent setting of the 0x80 bit in addition to the ESC prefix. >>> >> >> -- >> Thomas E. Dickey >> http://invisible-island.net >> ftp://invisible-island.net >> > > Thanks for all the attention to the keycodes problem. > > > On this end, I do not have time to think deeply or to investigate more > deeply until I get a stack of differential equations finals and then > another stack of linear algebra finals graded (should be doing that right > now, but this is more pleasant). > > However, this is what it looks like from here, reading the discussion in > this thread: > > 1. apparently X has changed some of its defaults. Should they have done > that? That is a very good question and I do not know the answer to things > which are outside the scope of my work.
Not exactly: I noticed that xterm was (essentially the only terminal)
implementing the "meta" feature as described in the terminfo document.
But there was no way to turn it on/off. So I added a new control
(escape) sequence so that applications could use that feature properly.
However, it turns out that readline has some ("15 years")
code that turns on the feature if you tell it that it's there.
It was discussed on gnu.bash.bug at the beginning of February 2007.
(the same thread's on bug-ncurses).
The terminal description tells what the terminal can do -
it's up to the application running in the terminal to
make effective use of the information. I pointed that out
last year, got no response from bash's maintainer.
> 2. apparently KDE in reaction has changed some of its defaults, too, or
> has always coded their terminal support this way, possibly anticipating a
> problem which now has happened but the lightning struck somewhere else.
> Should they have taken this approach? That is a good question, too, is it
> not?
KDE's terminal "konsole" implements what is essentially a part of the
meta feature. (Call it about 1/4). And since there's no escape sequence
to turn it on/off, we don't have to worry about what its effect is.
> 3. The MC mailing list (where I reported the same problem) thought it was
> not their issue. I can understand their attitude, but as I said in
> reaction to something that looked similar here, too, I do not think that
> this is the most constructive attitude which is possible.
I didn't notice the comment on MC's list (which I do read), but
noticed it here.
--
Thomas E. Dickey <[EMAIL PROTECTED]>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature
