Re: lynx-dev "sticky" things

[Vlad Harchev]

On Sat, 16 Oct 1999, Klaus Weide wrote:

> On Sat, 16 Oct 1999, Vlad Harchev wrote:
>[...] 
> >  English is not my native language, and I know it
> (nor mine; I'm sure the "natives" notice.)

  That's why I understand you better than others :) 

> 
> I suggest to change some details:
> 
> > CONFIRM_TEXTFIELD_PREV_DOC:NEVER|IFEDITED|ALWAYS
> >
> >  If value is NEVER, PREV_DOC_QUERY will be never asked,
> >            IFEDITED - old behaviour
> >              ALWAYS - ask always.
> 
> PREV_DOC instead of LEAVE_DOC - well, it's already the name of the key
>                                 action

  IMO such name collision is unimportant and shouldn't scare. And I find the
name I suggested -  CONFIRM_LEAVE_DOC_IN_TEXTFIELD - to be more descriptive to
russian-speaking users at least :)

> no _IN_ - to make it a bit shorter (but if you disagree, fine)
> no IFFORMCHANGED - that would seem to indicate that we check whether
>                    the form as a whole (any field) changed.

  I have a feeling that you don't wish to write the function that checks
whether the form has changed - am I right? Seems such function is already 
present: GridText.c:HText_HaveUserChangedForms. What do you think about it?

> IFEDITED (or IF_EDITED?) - maybe.  to not give the impression that
>                            a different kind of change has something to
>                            do with it?  Or leave as IF(_)CHANGED.

  I don't understand your comment about IFEDITED. But I find now IF(_)CHANGED
to be more correct.
   
>[...] 
> Will -> won't doesn't make it any more (or less) correct, in my understanding
> of English (which might be wrong).  It doesn't say which of TRUE/FALSE has
> one effect and whcih the other, either way.  If you want it to say that
> (and I think you should), it should be spelled out.  As in many of the
> good old options, "If XX is set TRUE, ...".

  OK.
 
> I really want to get rid of "sticky", problem is I don't have a really
> good different name.  Some were proposed
>  <http://www.flora.org/lynx-dev/html/month0799/msg00771.html>
> (maybe more in other messages).  (That's for sticky-the-1st, s-the-2nd
> is going to get renamed anyway it seems.)
> 
> Below you eliminated the 'goto again' branch.  That was another source
> of confusion: was that meant to act differently from falling through
> to 'default:' ?

 I don't know/remember. Most probably I forgot of that possibility.

>[patch skipped] 
> ... and then we can get rid of the NO_NONSTICKY_INPUTS symbol completely...

  Yes, we can.
 
> >   The behaviour the patch introduces:
> > if textfield_stop_at_left_edge is true (controlled via STICKY_FIELDS), then 
> > for each extra keypress lynx will ask PREV_DOC_QUERY text 
> > ('Do you want to go back to the previous document?' in English) with default
> > answer NO. The fact that default answer is NO means that any key other than
> > corresponding to YES will mean NO (arrow-left will mean NO too).
> 
> Yes, just like before *when* it issued the prompt.
> 
> >  While writing the patch, I found an incorrectness of the name INPUT_FIELDS
> > and it's description. The value TRUE of INPUT_FIELDS turns on new behaviour,
> > while it shouldn't according to the description, and viceversa. 
> 
> YM STICKY_FIELDS(?)

  Yes. I meant that in order description of INPUT_FIELDS to be correct, the
value read from that settings should be logically negated before writing to
'textarea_stop_at_left_edge'.

> >   But I feel that you'll welcome the more general 
> > CONFIRM_LEAVE_DOC_IN_TEXTFIELD described in the middle of the message, so 
> > that
> > the textfield_stop_at_left_edge will be removed, and some variable like 
> > confirm_leave_doc_in_textfield will be introduced. 
> 
> Yes, please. :)

  I'll do it later today (unless you criticize the
use of HText_HaveUserChangedForms).

>[...] 

 Best regards,
  -Vlad