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.
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?
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.
4. FVWM has up to this point said it is not exactly an FVWM problem,
either.
5. Me: It looks from this side as though there are a bunch of developers
who are doing projects that in fact are interdependent and each relies on
the other one doing things a certain way. But then project X changes
the way that something was done, and projects Y and Z go off in some
other direction or do not notice what project X did, which changes the
outcome of what they are doing.
Quite rightly, nobody would say that here is a bug in my project. Quite
rightly, nobody would say that there is a bug in that other project,
either, which is causing the problem. That would be a very irresponsible
attitude. Note that I don't share that attitude, either.
However, there is in fact a problem, and I do not believe that things like
this can be straightened out unless there is more contact between the
various groups of developers. for, the effect is a negative and
frustrating user experience which I would think that none of us want. Our
software is supposed to work, and smoothly, too. We are not supposed to
let things like that happen. Leave that kind of screwups to the Great
Monopolist, whose software does not seem to need to be attractive and
pleasing.
Solutions?
My ad hoc solution was to create an .Xdefaults file which changes the
default behavior of xterm. Ought this to be the universal solution? Not
sure about that.
Why did X use those new keyboard mappings? Could it be that the
"funny-looking" characters ought to be printed, because some people want
or need them? So this "solution" turns that off. As my wife would say, who
is Hungarian, "Nem joo." That is not typed right. To do that, it would
require a couple of those characters with accents on them, which I cannot
create now. But it means the same as "No good." Thus, the KDE solution of
avoiding the problem altogether might not be the good way to resolve this,
after all.
Could the proper solution be that MC could avoid the problem, by changing
their code to "and" the control character with 0x7F? Perhaps. I did not
have time to look at their code, or yours, to see how this ought to be
done. Perhaps I will, if I get time.
The point is, that we are all in this together. Thus, what ideally ought
to happen is that a consensus is reached about exactly who is responsible
for what. I do not have the answers. I just notice that this has not
happened,
A couple of other pieces of data about when the problem occurs and when
not, which I did not previously mention:
1. There is no problem at all in the Linux VT. The problem has arisen only
in X.
2. There is no problem in X, either, if one is running an rxvt window
instead of an xterm window. This was tested _before_ I created the
.Xdefaults file yesterday. So rxvt is presumably setting things up
differently, too.
Cheers,
Theodore Kilgore
