On 3/23/10 8:18 PM, Thomas Dickey wrote:
> On Tue, 23 Mar 2010, Chet Ramey wrote:
>
>> On 3/23/10 6:24 PM, Thomas Dickey wrote:
>>> On Tue, 23 Mar 2010, Chet Ramey wrote:
>>>
>>>>> I see (it would have been nice if Chet Ramey had responded to the bug
>>>>> report in October - I updated my faq to address this detail).
>>>>
>>>> I did. I sent the following questions (I have more, but this is a
>>>> start).
>>>> They were ignored, so I went on without the information.
>>>
>>> My email says that I did respond to the mail you're quoting; that was
>>> the last on that thread in October.
>>
>> You didn't, actually. The last message I have from you
>> (<20091007005807.gb24...@invisible-island.net>) is a response to
>> <4acb5fd8.5080...@case.edu>, an earlier message in the sequence.
>>
>> If you answered the questions I quoted, please resend that message and
>> we'll go on from there.
>
> Don't you have my email from 06 October? (If it were on the Novell bug
> report, it would be easier to reference).
I do. The message-id I referenced is from 6 October. It didn't answer
my questions.
> All of the features in a terminal description are optional (or advisory,
> depending on what term you prefer). They only tell the application
> whether a terminal supports a feature and/or how to achieve a given
> function.
True. And the xterm terminfo description says it has a meta key that can
be used as a modifier to send characters with the eighth bit set, and that
that feature can be enabled by sending a key sequence.
> The point of the bug report and followup discussion was that some users
> prefer to switch off the mapping of eight-bit characters, to get the
> escape character prefixing modified keys
And now they can. We moved beyond that even while discussing the previous
bug report. We're talking about whether or not xterm reveals anything to
the application running inside it about the current state of its
resources (it doesn't) and whether it dynamically reflects changes in those
resources to an application (it can't). Good enough.
Given that, the issue is now how to appropriately set the default value of
the enable-meta variable. That's the current question, and it was the
question we were considering before.
Another question is why xterm honors the smm sequence and allows the Meta
key to act as an eight-bit modifier when eightBitInput and
metaSendsEscape are false. Should xterm's behavior in response to terminfo
sequences always be consistent, or should it depend on the current
settings?
>
> man 5 terminfo
>
> 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.
I agree that terminfo is a poor mechanism to use when terminal capabilities
can change dynamically. Unfortunately, it's what we have.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
