[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev renaming and refinement of ex-STICKY_FIELDS (was "sticky" t
From: |
Vlad Harchev |
Subject: |
Re: lynx-dev renaming and refinement of ex-STICKY_FIELDS (was "sticky" things) |
Date: |
Mon, 18 Oct 1999 06:06:05 +0500 (SAMST) |
On Sun, 17 Oct 1999, Klaus Weide wrote:
> On Sat, 16 Oct 1999, Vlad Harchev wrote:
> Having PREV_DOC in the name shows what it is related to, even
> a simple text search gives some related info.
The user should now about the existance of PREV_DOC key. IMO very few do
(even users that use lynx for several years but who didn't change
keybindings). But let's go your way and assume that everybody knows
keyactions.
> 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. :)
True for variable names.
> > 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.
OK, let's choose your ideal (and you will be responsible for that name in
the changelog).
> > > > > 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.
Thanks, really! It seems to me that I would written the code with this
mistake.
Sorry for the absence of patch yet. I don't know when I will be able to code
it properly (in the next 2 days).
> Klaus
>
Best regards,
-Vlad
- Re: lynx-dev "sticky" things, and a half-serious proposal, (continued)
- Re: lynx-dev "sticky" things, and a half-serious proposal, Klaus Weide, 1999/10/18
- Re: lynx-dev "sticky" things, and a half-serious proposal, Leonid Pauzner, 1999/10/18
- Re: lynx-dev "sticky" things, Leonid Pauzner, 1999/10/16
- Re: lynx-dev "sticky" things, mattack, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/16
- lynx-dev renaming and refinement of ex-STICKY_FIELDS (was "sticky" things), Klaus Weide, 1999/10/17
- Re: lynx-dev renaming and refinement of ex-STICKY_FIELDS (was "sticky" things),
Vlad Harchev <=
- Re: lynx-dev "sticky" things, Philip Webb, 1999/10/16
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/17
- Re: lynx-dev "sticky" things, Klaus Weide, 1999/10/17
- Re: lynx-dev "sticky" things, Vlad Harchev, 1999/10/17
- lynx-dev Siberian soldiers' time, Philip Webb, 1999/10/24
- Re: lynx-dev Siberian soldiers' time, Juan-Carlos Lerman, 1999/10/24
- Re: lynx-dev Siberian soldiers' time, Vlad Harchev, 1999/10/24
- lynx-dev coding style, ifdefs, Klaus Weide, 1999/10/16
- Re: lynx-dev coding style, ifdefs, Vlad Harchev, 1999/10/16
- Re: lynx-dev coding style, ifdefs, Klaus Weide, 1999/10/16