Re: lynx-dev "sticky" things

[Vlad Harchev]

On Sat, 16 Oct 1999, Klaus Weide wrote:

> On Sat, 16 Oct 1999, Vlad Harchev wrote:
> > On Sat, 16 Oct 1999, Klaus Weide wrote:
> > > I suggest to change some details:
> > > On Sat, 16 Oct 1999, Vlad Harchev wrote:
> > > 
> > > > CONFIRM_TEXTFIELD_PREV_DOC:NEVER|IFEDITED|ALWAYS
> > > >
> > > >  If value is NEVER, PREV_DOC_QUERY will be never asked,
> > > >            IFEDITED - old behaviour
> > > >              ALWAYS - ask always.
> 
> I have an addition to propose:  IF_NOT_EMPTY. 
> If the field is completely empty, the Left Arrow keystroke was most likely
> not meant for moving around within the field.  (It wouldn't make sense.)
> Most fields in pages are not pre-filled with anything (in my experience),
> so they wouldn't "trap" unless one had started to edit.
> If the field is empty, there is no edited data to lose (in this field anyway).
> It seems to be a better heuristic than the one used now (IFCHANGED /
> IFEDITED).  It protects against more cases of accidental leaving.
> 
> Does it make sense?
  
 Yes, I like it.

> > > 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 :)
> 
> I strongly prefer *_PREV_DOC_* over *_LEAVE_DOC_*.  Or propose to
> rename the PREV_DOC key to the LEAVE_DOC key, too.

  I think your preference of _PREV_DOC_ over _LEAVE_DOC_ just because there is
a key action with the same name. IMO when user tries to guess the option
meaning, the names of key actions belong to different domain:) I prefer
_LEAVE_DOC just because LEAVE is a verb and a noun, while PREV is neither of
them (subjunctive?) and make less sense. This is a thing the lynx-devers can
vote for (ie voting for name).
 
> Ignore all my other changes as you prefer, but consistency should have
> some value.

  We both try to be consistent, but we have different POVs/understandings.  

> > > 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?
> 
> Hmm, feature "bloat"?  or "feature creep"? :)

  I hope you don't critize its existance :)

> I don't know whether it would be useful.  Maybe it is.
> 
> But that function checks *all* form fields in the current page.  So
> it should be IFFORM*S*CHANGED.

   This is exactly what is required. Yes, name should be IFFORMSCHANGED
   But I don't know, may be we should substitute the strings with numeric
codes?
 
> > > 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.
> 
> I was thinking about a Reset action for example, which does a
> "change" that consist of changing back to the "unchanged" value.

  This doesn't make things clear to me, but seems it's idealization again...

> But nevermind.
> 
>    Klasu
> 

PS: I will write the code tomorow (ie 12 hours later - I try to sleep at
nights - unlike you). Sorry. You can write the code if you wish.

 Best regards,
  -Vlad