Re: lynx-dev (key) Hex-ASCII values. . . ?

[Klaus Weide]

On Tue, 30 May 2000, pAb-032871 wrote:
> I'm not sure how 343 and 0x157 turn into 0527. . .  Octal?

Yes, leading 0 means octal in C.
Even bash understands it :)

   $ echo $(( 0527 ))
   343

> > I don't know why that's seen in MacLynx, since I have no idea how it's
> > compiled, but it appears to use a curses library similar enough to
> > ncurses (and have keypad() enabled).
> 
> It can tell the difference between "4" on the keyboard and "4"
> on the keypad if that's what keypad() enabled means [a simple
> test, using g)oto or the text entry field in a form; 4 on the
> keyboard types a number "4", but 4 on the *keypad* moves the cursor
> back one place with numbers-as-arrows].

The function keypad() needs to be called by an application in order
to get KEY_* symbols delivered from the curses library.  It that isn't
enabled, it would get keys in some unprocessed form.  In Unix etc. -
as several separate byte of an escape sequence.  On Mac - ???

> [Note: I should try the Enter binding with numbered links too.]
> 
> It uses curses for the Mac (c) 1994 by Robert Zimmerman.  Adapted
> from the same libraries?  A "Terminal" subfolder in the Alpha5
> source archive [last alpha release before Beta1] contains curses.c,
> curses.h and some Mac-specific sources; macurses.h, v_maccur.c,
> v_maccur.h, and v_maccur.r [while the actual code is still mostly
> gibberish to me, there is some useful, layman-readable info in
> the comments].
> 
> I found the line you quoted ["#define KEY_ENTER"] in curses.h
> at line 362 [by the way, that's *DECIMAL* 362 ;-) ] with soft-wrap
> turned off.  I should find a current library and see if they're
> the same or similar [by file comparison, not just line numbers].

Time to learn about 'diff'. :)

The "#define KEY_ENTER" happens to be in line 1150 in my case.  On
some other machine I found an ancient-looking ncurses.h (""1.8.6/ache")
where it's line 479, but still with the same value.  Not that it means
anything...

> This also occurs twice in v_maccur.c, at lines 742 and 824:
> [everything except the ENTER mapping snipped]
> 
> /****
> * The following "keypad map" maps various non-ascii keystrokes to
> * their curses KEY_xxx equivalents.  This could be made global so
> * that user supplied replacements could be linked in (but who would
> * want to go to all that trouble).
> ****/
> 
>  KEYPAD_MAP;
> 
> #define OlMapping
> #ifdef OlMapping
> static KEYPAD_MAP dflt_keypad_map[] = {
> /* 4C enter */                {KEY_ENTER, KEYMAP_NOCODE, KEYMAP_NOCODE, 
> KEYMAP_NOCODE},
> };
> 
> #else 
> 
> static KEYPAD_MAP dflt_keypad_map[] = {
> /* 4C enter */                {KEY_ENTER, KEYMAP_NOCODE, KEYMAP_NOCODE, 
> KEYMAP_NOCODE},
> };
> #endif
> 
> /********
> **
> **    maccur_key_trans:  Return curses key code based on keystroke event.
> **            If key has no entry in translation table, or entry is 
> KEYMAP_NOCODE,
> **            return ascii value.
                       ^^^^^^^^^^^

Whatever that means...  Just what *is* the "ascii value" of a *key*?
There is no ASCII code for "Enter", only for such things as Carriage
Return and Line Feed which are not keys...

The 4C (and 7D, below) is probably a system (hardware?) keycode
that identifies the key uniquely before translation.

> **
> **    Returns:
> **            Character translation of keystroke (type chtype).
> **
> **
> ********/
> 
> 
> The "#else" is a fallback set if none are defined in the first
> set?

Both alternatives are identical here, there's no need for #if ...
#then ... #else ...

> Maybe the NOCODEs are to blame; blank values with no substitute
> mapping that MacLynx can understand.  Maybe it was assumed that
> an unmodified Enter would be handled correctly.

Well it works, if the application recognizes 343 (aka KEY_ENTER) as
meaning "Enter key" and does something reasonable with it.

> For comparison, a different line shows:
> /* 7D down arrow */   {KEY_DOWN, KEY_NPAGE, KEY_END, KEYMAP_NOCODE},

I assume the four different values are for {key alone, key+shift,
key+command, key+???} or similar.

> The "lower keycode level" might actually be what it's reading.
> ie: it could be recieving direct keyboard input without any filtering
> by the system [or maybe filtered through the curses libraries,
> *instead* of through the system.  The line about "keystroke events"
> instead of "characters" makes it seem likely].

Something like that...
But I'm only speculating anyway when it comes to Macs.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden