10:23 a.m.
Martin Buchholz <martin(a)xemacs.org> writes:
The right fix should not do a remprop.
Then I suggest that help-char should be changed to '(control h)
and that tty the code in
if (XEVENT (event2)->event_type != key_press_event)
retval = 0;
else if (CONSOLE_TTY_P (XCONSOLE (EVENT_CHANNEL (event))))
{
int ch1, ch2;
ch1 = event_to_character (event, 0, 0, 0);
ch2 = event_to_character (XEVENT (event2), 0, 0, 0);
retval = (ch1 >= 0 && ch2 >= 0 && ch1 == ch2);
}
else if (EQ (event->event.key.keysym, XEVENT (event2)->event.key.keysym)
&&
event->event.key.modifiers == XEVENT (event2)->event.key.modifiers)
retval = 1;
else
retval = 0;
be changed such that it does not try to compare characters but be more
intelligent.
Jan
1:25 a.m.
New subject: Help-char bogosoties [was Re: delete-key-deletes-forward]
>>>> "Jan" == Jan Vroonhof
<vroonhof(a)math.ethz.ch> writes:
Jan> Martin Buchholz <martin(a)xemacs.org> writes:
> The right fix should not do a remprop.
Jan> Then I suggest that help-char should be changed to '(control h)
Jan> and that tty the code in
Jan> if (XEVENT (event2)->event_type != key_press_event)
Jan> retval = 0;
Jan> else if (CONSOLE_TTY_P (XCONSOLE (EVENT_CHANNEL (event))))
Jan> {
Jan> int ch1, ch2;
Jan> ch1 = event_to_character (event, 0, 0, 0);
Jan> ch2 = event_to_character (XEVENT (event2), 0, 0, 0);
Jan> retval = (ch1 >= 0 && ch2 >= 0 && ch1 == ch2);
Jan> }
Jan> else if (EQ (event->event.key.keysym, XEVENT (event2)->event.key.keysym)
&&
event-> event.key.modifiers == XEVENT (event2)->event.key.modifiers)
Jan> retval = 1;
Jan> else
Jan> retval = 0;
Jan> be changed such that it does not try to compare characters but be more
Jan> intelligent.
The very idea of a single help-char is bogus. I want (control h),
help, and f1 ALL to be equivalent as help-chars.
In any case, Jan and Glynn, you guys are technically compietent.
Think hard about how to do character frobbing right, 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.
Oh, and do you really want C-q Backspace to trigger
key read cannot be inserted in a buffer: #<keypress-event backspace>
??
The reason I think we should keep the ascii equivalences of backspace
and delete is that these very names are enshrined in the ASCII standard.
This is not in any way a veto.
Martin
3:13 a.m.
New subject: Help-char bogosoties [was Re: delete-key-deletes-forward]
Martin Buchholz wrote:
The very idea of a single help-char is bogus. I want (control h),
help, and f1 ALL to be equivalent as help-chars.
... or help-keysyms even.
In any case, Jan and Glynn, you guys are technically compietent.
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.
Think hard about how to do character frobbing right,
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.
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.
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?
Oh, and do you really want C-q Backspace to trigger
key read cannot be inserted in a buffer: #<keypress-event backspace>
??
Yes. For the same reason that C-q {Home,End,PgUp,...} et al generate
the same message.
The reason I think we should keep the ascii equivalences of
backspace
and delete is that these very names are enshrined in the ASCII standard.
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>
9350
days inactive
9351
days old
2 comments
3 participants
participants (3)
-
Glynn Clements -
Jan Vroonhof -
Martin Buchholz