[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev "sticky" things
From: |
Vlad Harchev |
Subject: |
Re: lynx-dev "sticky" things |
Date: |
Sat, 16 Oct 1999 14:44:15 +0500 (SAMST) |
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
- 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, Vlad Harchev, 1999/10/18
- 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, Vlad Harchev, 1999/10/18
- 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 <=
- 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, 1999/10/17
- 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