Re: Help-char bogosoties [was Re: delete-key-deletes-forward]

Martin Buchholz wrote: ... or help-keysyms even. Jan may be. Just looking at .c files which include lisp.h scares the shit out of me. No doubt I'll learn about XEmacs' internals one day, but now isn't a good time for me to be starting anything long-term. This begs the question of whether `character frobbing' is right. At first glance, there seems to be too much stuff dealing with characters. Would I be correct in assuming that some of this stuff predates X, back to a time when all input was ASCII? Presumably there is some reason why the help-char/help-form stuff needs to be performed in next-event, but I don't know what it is. The way that event_matches_key_specifier_p works, by checking whether the arguments both correspond (in some sense) to the same ASCII code, seems to be indicative of the underlying ASCII-ism which still exists. IMHO, the only cases where there is really any `natural' correspondence between keysyms and ASCII codes are the keys which would actually cause something to be printed if the keyboard was part of a typewriter. Function keys, the grey keys around the edges, and anything pressed in conjunction with Ctrl/Meta/Alt/... don't `naturally' correspond to ASCII codes (wait until XEmacs/Win32 has been around for a while, and then see how `natural' the average user thinks the correspondence between the Backspace key and Control+H is). They may have `historical' correspondences, but I really don't think that's relevant any more. To my mind, the only exception is the desire to support text terminals. 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? Does removing last-input-char altogether constitute changing its semantics? :) I notice that its docstring currently says: : 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? IOW, is there a good reason for any code to process input in terms of characters, rather than keysyms? Yes. For the same reason that C-q {Home,End,PgUp,...} et al generate the same message. So what? If X had used the keysyms `DeleteLeft' and `DeleteRight' instead, would that make a difference? Why is the coincidence between X's keysym names and ASCII control-code names relevant? In fact, of what relevance is the ASCII standard? 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. -- Glynn Clements <glynn(a)sensei.co.uk&gt;