Re: 0.15.x -> 0.16.x

["Jason M. Felice" <jasonf@xxxxxxxxxxxxxxxx>]

On Tue, Jan 18, 2000 at 08:27:43PM +1300, Carey Evans wrote:
> "Jason M. Felice" <jasonf@Baldwingroup.COM> writes:
> 
> > Hmm, interesting.  Is there really a difference between pressing field exit
> > when on the last character of the field and pressing field exit after typing
> > the last character, but still on the last character in a Field Exit Required
> > field?  Catch-22 - I don't want to add YASF (yet another state flag).  What
> > if you typed up to the end of the field, but then want to clear the last
> > character with Field Exit?
> 
> There *is* a difference between before entering the last character in
> a field, and having entered the last character and waiting for Field
> Exit.  ISTR a real 5250 terminal that changed the cursor appearance in
> this case.
> 
> How I think this works:
> 
> We have a four-character field, for instance:      ____
>                         with the cursor here:      ^
> 
> Enter three characters:                            ABC_
>                                                       ^
> 
> Enter the fourth character, and the state changes: ABCD
>                                                       ~
> 
> Now if the user presses Field Exit, all the associated processing is
> done, and the cursor moves to the next field.  If the cursor is just
> positioned over the fourth character:
>                                                    ABCD
>                                                       ^
> and field exit is pressed, then the final character is erased, and the
> cursor moves to the next field.
>                                                    ABC_     ____
>                                                             ^

Just like IBM, so much work for an exceptional case instead of designing the
blasted thing so there are few exceptional cases. </rant>

On the other hand, that's a very clear description (including what the other
poster posted, thanks), and I should be able to implement that fairly easily.

> [...]
> 
> > We are now handling Home key according to spec, which doesn't seem to jive
> > 100% with what you're saying, but it's a lot closer than what we *were*
> > doing :)  I also checked against Mocha5250 before abiding by the spec.
> 
> Here's what I see in Client Access.  I edit a file in SEU, move the
> cursor to one of the line numbers, and press Enter.  The line number
> gets highlighted, and the cursor moves to the beginning of the line.
> Now I move the cursor up a few lines and press Home, and the cursor
> returns to where it was after pressing Enter.  Up to here, tn5250
> behaves the same.
> 
> However, if I now press Home again, the cursor moves to the command
> line at the top of the screen in Client Access.  Nothing happens in
> tn5250.

Would this pseudo-code be the "correct" implementation?

when Home is pressed:
   -- This part is not in spec.
   if currently in field
     if not at beginning of field
       move to beginning of field
       return to caller
     endif
   endif
   -- The rest is in the spec.
   if at home position
     send record backspace
     return to caller
   endif
   move to home position
   return to caller

> 
> [...]
> 
> > There seems to be an intermediate way to do this - tell curses not to parse
> > key codes and parse them ourselves.  It looks like we can be smarter about
> > it.  (I wonder if that can be considered a ncurses bug?  Its probably doing
> > something *really* generic).
> 
> I think ncurses tries to be bug-for-bug compatible with SVR4 curses,
> where possible.

I hope not :)

> 
> Hmm.  How does cursesterm.c notice when something has to get done?  If
> it's only waiting for keypresses, but ncurses is waiting for a delay
> to decide whether our Meta-key is an escape sequence or not, then
> ncurses won't get a chance to report it until the next keypress.  This
> sounds very much like what we're seeing.

When we call getch() and there is an ESC queued, curses should do the 
equivalent of another getch() with halfdelay set on, meaning that it will time
out in x/10ths of a second.  If it times out, it should return ESC.  Of course,
we're telling curses to never block, (so we can handle data received from
host whenever it arrives), so...  The more I think about it, the more I think
it's definitely a bug or an oversite.

I've devised a rather nifty method for handling those keys
ourself and not requiring the delay.  When the emulator fires up, we read the
termcap/terminfo entries for all the keys that we handle and we populate which
one into a tree structure, one key per node.  Terminal nodes get marked with
the 5250 key to return, half-terminal nodes (nodes which could be terminal, or
there may be more data) get marked as such, and we use curses halfdelay() to
determine if there is another character pending at that point.

After we populate this with the terminal's key sequences, we populate it with
our ESC-A, etc., magic, and treat those key sequences like function keys.

This would mean there's no delay for ESC A on a terminal where ESC [ introduces
all function key sequences, as we know as soon as we get an 'A' that we have
K_ATTN.

> 
> [...]
> 
> > Is it a bug or a feature?  I can't think of any case where this would hurt
> > anything, and it seems pretty useful to me.  Is it annoying to any 5250
> > veterans?
> 
> I noticed it when trying to type *PARMS in the from position of a
> field in a system data structure in ILE RPG.  I could learn to cope
> with it just by pressing Tab instead.
> 
> [...]
> 
> > Good argument for the key-to-5250-function map.  Wait - does X allow us
> > to use a different vt100 translation for the number-pad - and +?  I'll
> > look into that.  And the console, too.  (Ugh, linux key maps)
> 
> In application keypad mode, with num-lock off, xterm sends "ESC O k"
> instead of "+" for the keypad plus key.  This doesn't seem to be in
> the terminfo description.  XTerm should be able to tell the difference
> from X, though.

Of course, this points out that not all key sequences in an xterm start with
ESC [, drat.  I still think my method would require less key delays, but now
I must make sure before implementing :(

> 
> -- 
>        Carey Evans  http://home.clear.net.nz/pages/c.evans/
> 
>        This message was composed from the finest electrons
>        used by many of the world's greatest writers.

-Jay 'Eraserhead' Felice
+---
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---