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

[pAb-032871]

In "Re: lynx-dev (key) Hex-ASCII values. . . ?"
[30/May/2000 Tue 20:54:13]
Klaus Weide wrote:

> 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 :)

Hmm, I've understood all the different bases on my own terms,
but never picked up the accepted vocabulary: in a hex editor,
you always know "10" is a hex rendering of 16.  But compilers
don't know this, and neither do the people you talk with.  That's
why I was using terms like "hex:10" and "dec:16".  Should be easy
to drop the habit now [a bad one, I'll admit], before it becomes
second nature.

0625 = 500 = 0x1F4. . .  Words to live by.

> > It can tell the difference between "4" on the keyboard and "4"
> > on the keypad if that's what keypad() enabled means
[...]
> 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 - ???

0x157 is two bytes, but that's Lynx's internal symbol for the key.
What you said about internal hardware keycodes might be it.

The system could actually be *using* internal representations for
various non-ASCII codes [such as 0x03 for Enter] to ensure that
applications and the system all have a common language to communicate
with eachother [similar to Lynx spawning Pico to write mail, and
Pico returning the finished document to Lynx when it's ready to
send].  Fairly straightforward, until Lynx or something immigrates
from another platform and tries to figure out the local dialect. . .


> > [...] 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'. :)

BBEdit has a Find Diffs capability, for comparing two files on a
line-by-line basis.  It isn't fooled by the same string occurring
at different line numbers either.  So far I've only used it to
check separate LYNXKEYMAP saves and isolate custom-mappings, so
there could be a lot of unused potential there.

But as a file format, I don't know how diffs work.  A rough guess
would be something like;

    del;"old string 1"
replace;"del;`old string 2',add;`new string 1'"
    add;"new string 2"
    add;"new string 3"
etc.

which leaves unchanged items completely out of the file and saves
space.  Is this even close?

ResCompare might be a better example [a freeware patching utility].
As the name says, it compares two files -- usually two versions
of the same application program -- and examines them looking for
unique resources, plus resources of the *same* type and ID number
but containing different data, while ignoring identical items.
Once it's assembled a complete list of changes, it compiles *only
the differences* [ie: not complete resources, unless they're totally
absent in the older version] into a new, self-standing application,
which can then be downloaded and aimed at old versions to update
them.


> > [everything except the ENTER mapping snipped]

>From your questions, and after a second look, I really chopped
WAY too much from the last message.  Sorry, I was trying to stick
to the subject and skip [what seemed like] irrelevant distractions.

Here it is again, with cuts ######## clearly marked ########.
Some tabs cut too, because it looks like this was written for 4
spaces/tab [Internet standard is 8?].

Example starts at line 696:

/****
* 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).
****/

#define KEYMAP_BASE 0x33        /* Key number of first key to translate. */
#define KEYMAP_TOP (KEYMAP_BASE + sizeof(dflt_keypad_map)/sizeof(KEYPAD_MAP))
#define KEYMAP_NOCODE 0         /* If this is key translation, return ascii 
code for that key.*/

typedef struct keypad_map_strct {       /* Determine what to do with 
key/modifier: */
        chtype basic_code;      /* This is translation of unmodified key. */
        chtype shift_code;      /* Translation of key with shift. */
        chtype opt_code;        /* Translation of key with option. */
        chtype shift_opt_code;  /* Translation of key with shift-option. */
} KEYPAD_MAP;

#define OlMapping
#ifdef OlMapping
static KEYPAD_MAP dflt_keypad_map[] = {
/* 33 delete */         {KEY_BACKSPACE, KEY_BACKSPACE, KEY_BACKSPACE, 
KEY_BACKSPACE},
/* 34 */                {KEYMAP_NOCODE, KEYMAP_NOCODE, KEYMAP_NOCODE, 
KEYMAP_NOCODE},
/* 35 */                {KEYMAP_NOCODE, KEYMAP_NOCODE, KEYMAP_NOCODE, 
KEYMAP_NOCODE},


######## CUT, missing a couple *pages* of specific definitions ########


/* 7C rt arrow */       {KEY_RIGHT, KEY_SRIGHT, KEYMAP_NOCODE, KEYMAP_NOCODE},
/* 7D down arrow */     {KEY_DOWN, KEY_NPAGE, KEY_END, KEYMAP_NOCODE},
/* 7E up arrow */       {KEY_UP, KEY_PPAGE, KEY_HOME, KEYMAP_NOCODE},
/* 7F */                {KEYMAP_NOCODE, KEYMAP_NOCODE, KEYMAP_NOCODE, 
KEYMAP_NOCODE}
};

#else 

static KEYPAD_MAP dflt_keypad_map[] = {
/* 33 delete */         {KEY_BACKSPACE, KEY_BACKSPACE, KEY_BACKSPACE, 
KEY_BACKSPACE},
/* 34 */                {KEYMAP_NOCODE, KEYMAP_NOCODE, KEYMAP_NOCODE, 
KEYMAP_NOCODE},


######## CUT again ########


/* 7E up arrow */       {KEY_UP, KEY_PPAGE, KEY_HOME, KEYMAP_NOCODE},
/* 7F */                {KEYMAP_NOCODE, 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...

That's a good question.  Going back to:

chtype basic_code;      /* This is translation of unmodified key. */
chtype shift_code;      /* Translation of key with shift. */
chtype opt_code;        /* Translation of key with option. */
chtype shift_opt_code;  /* Translation of key with shift-option. */

[...]

/* 4C enter */          {KEY_ENTER, KEYMAP_NOCODE, KEYMAP_NOCODE, 
KEYMAP_NOCODE},

Only the plain, UNmodified key, the first of those four, is remapped
as KEY_ENTER.  So when I tried Shift-Enter and Option-Enter [using
an almost-empty lynx.cfg for clean, defaults-only keybinding],
0x03 was passed *directly* to MacLynx.  ie: it asked me if I really
wanted to quit [reading the "raw" 0x03 as CTRL-C, just like you
had predicted].  Maybe this is what the "return ascii value" line
is about.

Actually, this was a good place to start because the "pseudo-ASCII"
value of the Enter key remains unchanged by all modifiers; a constant,
reliable 0x03.  Glad to avoid some extra guesswork there -- by
pure luck.

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

It must be.  The ASCII I get back from a down-arrow is 0x1F.

       Up:0x1E

Left:0x1C   Right:0x1D

      Down:0x1F

> > 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 ...

You're right [Find Diffs. . .0].  In the original, it looked like
the whole non-ASCII range was mapped, so I assumed a few small
variations without looking too closely.  Someone may have screwed
up there, or maybe they were planning to map new codes but never
got around to it.  This *is* the Alpha5 source.

> > 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.

Right,
KEY_DOWN = unmodified arrow,
KEY_NPAGE = Shift+down-arrow,
KEY_END = Option+down-arrow, and
KEYMAP_NOCODE = Shift+Option+down-arrow [understood as plain arrow]

I never knew about these modifiers because I use the keypad, and
these mappings only seem to affect the actual arrow *keys*.

Control and Command don't seem to change anything with the arrows
Maybe there's no need to map these because Control+keys are already
understood by Lynx and others.  The *only* Command+key combination
MacLynx seems to recognize is an unconditional quit [Cmd+q, Cmd+Q,
Cmd+period].  I thought this was a UNIXism, but maybe Control-modified
commands are easier to map and customize [Command-modified characters
are exactly like their unmodified versions, so *this* at least happens
outside of the character-set range].

> > 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.


That's okay, so am I!



                    Patrick
          <mailto:address@hidden>
 

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