Mail Archives: djgpp-workers/1998/01/21/08:31:10
On Tue, 20 Jan 1998, Markus F.X.J. Oberhumer wrote:
> That's what I meant. I assume your current code looks like
> this (scancodes pressed):
>
> (0x1d || 0x61) && 0x2b (left or right ctrl) + '\'
Functionally, yes, but not literally. The code looks at the keyboard
shift status byte in the BIOS data area instead of handling the
Ctrl/Shift/Alt scan codes directly.
> What I need is:
>
> (0x11 || 0x61) && 0x64 && 0x0c (left or right ctrl) + right alt + '-'
You can't, not without changing the DJGPP keyboard handler to look at
the extended shift status byte, because the non-extended byte doesn't
distinguish between left and right Alt keys. I didn't want to include
this since older keyboards don't support the extended shift byte, and
I didn't want to add the test for this support. It seemed like too
much of a hassle, since the QUIT key can be changed, even on Unix, so
programs which use it don't assume any hard-coded key for it.
The bottom line of this is that on keyboards that don't have the `\'
character you will have to change the QUIT character to make SIGQUIT
useful.
> I'd bet this is again different in lots of other locales.
Sure is. In fact, most of European keyboards don't like `\' at all
(it's ironic, I think, since it is so important for the PC).
> > (unless you change the scan code which triggers
> > SIGQUIT by calling `__djgpp_set_sigquit_key').
>
> Shouldn't this be termios c_cc[VQUIT] ?
I didn't change termios to support this feature yet.
`__djgpp_set_sigquit_key' and its sibling `__djgpp_set_sigint_key' are
meant to provide the low-level facilities to be called by termios and
its ilk.
> - should it be bound to a key by default ?
In the current implementation, it *is* bound. I think that a program
which does want to get SIGQUIT, should be able to do that with a
minimum of hassle. I certainly think that calling a function which
binds SIGQUIT to a key is too much of a hassle, especially since it
has to be done with DJGPP-specific code (which spells #ifdef's in
ported programs).
> - if yes, why shouldn't all programs receive it ?
They *do* receive SIGQUIT, but the default handler ignores it, since
some of the people I asked about this felt uneasy with adding a
feature whereby a keypress which was innocent in previous versions of
DJGPP will now abort the program.
Ignoring the SIGQUIT by default makes it analogous to SIGWINCH on Unix
which is also discarded by the default handler.
> - how do solve localization ?
In the current implementation, this is left to the application. If a
program wants to go international, it will have to do the necessary
bookkeeping to determine the code page in use and call
`__djgpp_set_sigquit_key' with an appropriate key code.
Alternatively, it could set a single key whose scan code is the same
on all keyboards.
> - is termios ready for some real-world tasks ?
I don't know, and currently I don't care. The motivation for the
changes that I posted here was in part triggered by the fact that in
DJGPP the INTR key is hard-coded to be Ctrl-C, whereas some programs,
rebind it to another key. A notable example of these programs is
Emacs, where the inability to remap SIGINT to another key changes the
operation of the DJGPP port in subtle ways that take a lot to explain
and document.
Changing the DJGPP keyboard handler to have a low-level facility that
supports user-defined INTR key was enough of a challenge for me to do
it first. If it works, we can worry about termios and other uses.
(One thing that worries me about termios is that it uses BIOS calls
throughout, evidently to work around this very problem of being unable
to define the INTR key. Personally, I think that when this obstacle
is no longer with us, termios should be rewritten to use the normal
DOS I/O. But don't ask me when, or even if, will I get to making this
happen. I was hoping that making INTR and QUIT keys user-definable
will persuade someone to do that. After all, termios was written by
somebody else, not by me.)
> Which are those programs, and what exactly are the different actions ?
One is Emacs. The other is an interpreter which uses SIGINT to break
out of long or runaway computation, and SIGQUIT to pause such
computations so that a user can do some debugging like print
variables, and then resume the interrupted code.
In general, any program that wants to let the user interrupt it in two
different ways will need both SIGINT and SIGQUIT.
- Raw text -