lynx-dev renaming and refinement of ex-STICKY_FIELDS (was "sticky" things)

[Klaus Weide]

On Sat, 16 Oct 1999, Vlad Harchev wrote:

> On Sat, 16 Oct 1999, Klaus Weide wrote:

> > > > 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
                                     (I meant: you should ^ )
> > 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. 

Indeed.

> IMO when user tries to guess the option
> meaning, the names of key actions belong to different domain:)

But it is exactly the key action PREV_DOC that we are dealing with here.

(To be exact, as long as the user has not mapped Left Arrow (0x103) to
something else with a KEYMAP option.  If the key has been remapped, then
THAT key action would be taken after a positive response, and nothing
can be guaranteed - neither that it is PREV_DOC, nor that it will
"LEAVE" the "DOC", nor that the prompt is appropriate.  So let's not
consider this case.)

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

MUMBLE_PREV_DOC_MUMBLE.

I don't like the tendency to introduce long option
NAMES_THAT_ARE_A_BIT_LIKE_SENTENCES_BUT_NEVER_QUITE_SO
(and which would -become_ridiculous_as_command_line_options).

Having PREV_DOC in the name shows what it is related to, even
a simple text search gives some related info.

In other words consistency is good and trying to make option names
completely self-describing is bound to fail anyway.  Maybe this is
just another case of you trying to get out of writing the appropriate
commentary. :)

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

You are trying to be consistent with some kind of human language
sentence ideal, which isn't consistent with the common style of the
older options (nearly all of them) nor with some of your own recent ones.
Or so it seems.  My ideal is simpler: give related things recognizably
related names.

> > > > no IFFORMCHANGED - that would seem to indicate that we check whether
> > > >                    the form as a whole (any field) changed.
> 
>   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.

Implementation detail: if you want to do this by calling
HText_HaveUserChangedForms() in that place we all love, you
have to additionally whether MyEdit.buffer has changed (and
probably combine both with '||').  Otherwise the current (last)
changes could get unnoticed, since they are not yet committed
to the form structure at that point.  Also, MyEdit.buffer
should then probably be compared against the 'form->orig_value' and
not the 'form->value' - or maybe both.

   Klaus