lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev "sticky" things, and a half-serious proposal


From: Klaus Weide
Subject: Re: lynx-dev "sticky" things, and a half-serious proposal
Date: Mon, 18 Oct 1999 14:14:02 -0500 (CDT)

On Tue, 19 Oct 1999, Vlad Harchev wrote:
> On Mon, 18 Oct 1999, Klaus Weide wrote:
> > On Tue, 19 Oct 1999, Vlad Harchev wrote:
> > 
> > >   You still may be joking. Or at least  complete "conditions can be 
> > > combined
> > > section" or so.
> > 
> > I am not sure about that one.  It falls under "details may vary..."
>  
>   IMO combining options is somewhat excessive, and the actions are somewhat
> non-orthogonal, not mutually exclusive (ie BEEP is the same as IGNORE, but
> with bell, etc). When such doubts arise, this means that the option is
> not properly designed.

So help improve the design.

I came up with combining (i.e. listing more than one 'action=condition'
pair) when I found there was a need for 'COMMIT'.  The others probably
need not be combinable, but it makes the syntax more orthogonal, and - who
knows - maybe it would be useful to say "IGNORE the key if the field has
been empty, otherwise produce a prompt".

Btw I came up with COMMIT when I played with various settings for
KEYMAP: to see how all this would interact with a changed Left Arrow
binding.  Try KEYMAP:0x103:DO_NOTHING, it's interesting...

> > Have you written something for LYForms.c beyond the example you had sent?
> 
>  No. But I feel that it is excessive - IMO old CONFIRM_PREV_DOC was much more
> atomal and orthogonal. 

I am trying to take account of the fact that some users (not just one)
wanted something different.  In addition, trying to put everything under
one option instead of several related ones (as Henry has often asked for).
[ But I don't think it should also subsume stick-of-the-1st-kind in some
way. they seem too different. ]

Of course that makes it more complex.

   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]