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

[pAb-032871]

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

> On Tue, 30 May 2000, pAb-032871 wrote:
[With ^Trace on. . .]
> > All it did was add "343" to the "press space for more" message.
> 
> I don't really understand why you could see that (didn't find the
> line that produces this output), but I'm glad it worked for you. :)

So am I!  Learned some interesting stuff along the way too.  And
here's some of it right now:

If you were looking in the Trace *window*, I don't know if you'd
see it either.  Here, it was appended to the statusline message.
Literally:
press space for more, use arrow keys to move, '?' for help, 'q' to quit. 343

Oliver Gutknecht may have added this as a debugging aid when he
was putting MacLynx together, I have no idea. . .  There was no
"real" trace output until I requested a new page, referenced from
the startfile.

The same trick might work for any unusual key, and luckily I don't
have to do all the decimal-to-hex conversions in my head [tiny
little 3k util does it beautifully].  The unrecognized Esc key
returned 27 [hex:1B] with trace on, and that *is* the ASCII value
of Escape on Macs, so it looks promising.


[The rest is more in-depth, but closer to "why-is" speculation
than "how-to".  Might be of interest though.]


> > KEYMAP:0x157:ACTIVATE
> > !!!!!!!!!!!!!!!!!!!!!
> 
> That's the same number as ncurses' keypad() token for Enter; from
> ncurses.h:
> 
>   #define KEY_ENTER       0527            /* Enter or send (unreliable) */

I'm not sure how 343 and 0x157 turn into 0527. . .  Octal?

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

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

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.
**
**      Returns:
**              Character translation of keystroke (type chtype).
**
**
********/


The "#else" is a fallback set if none are defined in the first
set?

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.

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


> You can use that code - obviously you want to, if you have no better
> way - but don't be surprised if it stops working in a future version,
> or in a lynx compiled differently.

Personally, I use Return or right-arrow for the web [a form entry,
followed by two quick Returns -- one to move off, the other to
submit -- is a lot like the "OK-button" keybinding from Mac dialog
boxes].  But I would like to give MacLynx more consistant, predictable
behavior if I can: both consistant with standard user input on
other platforms *and* more consistant with the MacOS interface.

Many help documents concerning Lynx use the word "Enter" instead
of "Return", which is okay on IBM-compatible machines because
both are usually one key [and again in Mac dialogs, Enter is also
accepted as confirmation from the user.  Esc and/or Command-period
are generally respected as "cancel"].

I'm not too concerned about different builds and future versions
because MacLynx hasn't been updated since 1997 [I don't know if
editing the compiled binary counts].  There might never *be* a
Beta2.  B1 seems reasonably stable, but if I can learn enough and
get the tools together, it would be nice to port a current version
[Maybe using the available Alpha5 source for reference].  At the
moment, porting or writing ANY kind of software is a pleasant
daydream for me.  Also, the lynx.cfg distributed with MacLynx
was fairly platform-specific before I ever started messing with
it [the fact that it came in a StuffIt archive should have been
my first clue].


> CTRL-C is obviously different from ENTER, despite the fact that some Mac
> tools happen to show the same code...

True, but it's not just *some* that show this code: ALL of them
do.

It may be the exact opposite to this, pasted directly from an
earlier message:
> That would be a Control-C character.  I somehow doubt that that's
> correct.  Maybe at some lower keycode level, but not at the ASCII
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> level at which lynx should see the characters.

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

As far as the OS is concerned, there's NO difference between CTRL-C
and Enter.  I tried one of the most basic system-level commands
-- emptying the Trash -- and when asked, confirmed the action
using CTRL-C.  CTRL-M [0D or carriage return] also worked.  No
application was involved except maybe the Finder [considered to
be "a system document which sometimes behaves like an application".
The MacOS can't boot or run without the Finder, and although it
normally doesn't accept the Quit command there are ways to *make*
it exit.  However, most of them result in a system crash.  Sorry,
but I don't think I'm *quite* that dedicated ;-) ].

> I think your lynx sees CTRL-C as 0x03, so a KEYMAP:0x03 should affect
> it.> (But on UNIX, lynx normally doesn't "see" CTRL-C as a character
> at all - it sees an interrupt instead, so the KEYMAP:0x03 would have
> no effect.  Unless CTRL-C does not generate an interrupt, which can
> be achieved with the stty command.)

I think 0x03 was a dead-end; totally unrelated to how MacLynx
interprets keystrokes.  Or maybe I just haven't found the key
MacLynx *does* recognize as 0x03.  Just out of curiosity, I did
try KEYMAP:0x03:GOTO, luanching MacLynx, and then typing CTRL-C.
Still asked me about quitting. . .


Totally off-topic, but this is interesting because MacLynx has
these unique entries;
TERM_LINES:
TERM_COLS:
in its lynx.cfg, which define the initial size of the Lynx window.

Also from v_maccur.c:


        int i, screen_chars;

        if (LINES == 0)                         /* looks like a hack, huh ? 
You're right */
                LINES = _maccur_lines;  /* it's necessary to have a custom 
startup screensize */
        else
                _maccur_lines = LINES;
        if (COLS == 0)
                COLS = _maccur_cols;
        else
                _maccur_cols = COLS;


Maybe it needs to refer to these values before it can build a
text-grid.



                    Patrick
          <mailto:address@hidden>
 

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