Glynn Clements <glynn(a)sensei.co.uk> writes in xemacs-beta(a)xemacs.org:
Martin Buchholz wrote:
> treat the source as if you owned it and just do it Right.
> And (re)read the comment at the start of event-stream.c.
Excellent advice.
Do you mean the
* DANGER!!
*
* If you ever change ANYTHING in this file, you MUST run the
* testcases at the end to make sure that you haven't changed
* the semantics of recent-keys, last-input-char, or keyboard
* macros. You'd be surprised how easy it is to break this.
bit?
Yup.
Does removing last-input-char altogether constitute changing its
semantics? :) I notice that its docstring currently says:
Yes. Grep through all the lisp packages for current usage of it.
: If the value of `last-input-event' is a keyboard event, then
: this is the nearest ASCII equivalent to it. Remember that there is
: NOT a 1:1 mapping between keyboard events and ASCII characters: the set
: of keyboard events is much larger, so writing code that examines this
: variable to determine what key has been typed is bad practice, unless
: you are certain that it will be one of a small set of characters.
Would `[pre]historic baggage: do not use' be a better docstring?
Is
there any compelling reason why code shouldn't be forced to use
last-input-event instead?
FSF Emacs compatibility. I'll defer to Martin if he disagrees, but I
would think a `do not use' docstring and obsoleting the variable would
be sufficient. I disagree strongly with removing it altogether
without fair warning and at least a year and a release or three with
it obsolete.
IOW, is there a good reason for any code to process input in terms
of
characters, rather than keysyms?
I don't think so.
...
In fact, of what relevance is the ASCII standard?
In a Mule world, none, I believe.
Does the underlying protocol need to be exposed to the user (beyond
what is inevitable on text terminals)? I would rather try to shoehorn
TTY-mode into the event-driven GUI framework than the other way around.
<AOL>
Me too.
</AOL>