lynx-dev adding options

[Heather Stern]

fortune cookie crumbs from a thread including Leonid Pauzner and 
  address@hidden (probably among others) bear the following 
  tasty bits:
> 
> > I like the new "verbose images" and "partial display" facilities.
> > ...
> >         Segmentation fault

I am beginning to see enough patches merged in, and corrections (I trust
this will be corrected probably by the time my msg pops onto the list)
that it is looking worthwhile for me to do a new fetch-and-make even though
I've little spare time these days.   Thanks everyone!

> > It would be nice if there were an "o" accessibel Option for partial
> > display that could be turned on and off while lynx is being used
> > interactively.
> 
> Unfortunately, the Options menu limited in the size to fit one page...

[I hope this doesn't seem too rambly;  I had a brainstorm and need to get
it into the list before it slips away.  I will not feel offended if y'all
use some of it and ditch other parts.]

It seems to me the Options could be broadly expanded by categorizing the
actual options, and turning them into a picklist of sorts.  We already
have code for handling picklists.

Er, maybe that's too vague.  I imagine something like this:

 [Goto Buffer      |v]     (*) on/true   ( ) off/false
 [external editor  |v]     /usr/bin/vi________________________
 Character Set: [ISO Latin 1                   |v]
   .  .  .

The first picklist would cover all options which are tweakable at runtime and 
are on/off.  The second would cover all options which require the user to
type their own thing, whether it's their own username, a path, URL, etc.

It'd be "intuitive" to me, if a bit strange, if when I twiddle the field
picklists, the value field it is tied to shows me the present value.  But
it would be a different way of handling picklists than the HTML forms code
does, so it might take a little extra work.  

It would pretty much be impossible to see all the options at once though.
Hmmmm.  Maybe splitting the logical groups into submenus would be a better 
idea:  

  The on/off ones could be arranged in columns (rather like ls -C or dir /w
  provides) with only the space for the checkmark, and lynx would be smart
  enough to sort out the TRUE/FALSE from 1/0, +/-, ON/OFF (if these aren't
  already one concept internally -- I think I saw someone saying that they'd
  done that).  

  Are there more than 20 fields that want fulltext settings?  Maybe they 
  could be split into the ones that want URLs and the ones that don't care, 
  and then validated seperately.

Of course if someone wants to come up with a CGI that uses plain English
to ask enough to craft a custom lynx.cfg (much as there are now several that
will ask a few dumb questions, then use a template to zip up and mail you a
web page set)... I bet it would be popular.  But it wouldn't solve the 
problem of setting runtime options... unless we have a "reload options from 
lynx.cfg" key?

The real problem as I see it is the need to explain the options (even with
a simple label), that there are so many, and that there are enough that we
can't expect consensus on which ones are important enough to keep or cull
from a limited page (folks' needs are too different).  

So maybe we could offer current or even "simpler" options to Novice users,
as compact as seems reasonable to Intermediate users, and some sort of
"completists" options menu (possibly with submenus) to Advanced users.  
TSX-BBS had *7 pages* of options, and they just didn't seem that hard to
traverse... I was "in option mode" until I made all my selections, then
saved them.  I could save or ditch all the presently buffered changes from
any page.  (It would have been nice to have a choice to have it show me
the buffered changes as a "burst listing" but that's gravy.)

Take what you like, feel free to shred as necessary until you like it.

Heather Stern -*- email address - star at:
starshine.org --- Starshine Technical Services -*- Sysadmin Support & Training
    lasfs.org --- L.A. Science Fantasy Society -*- de profundis ad astra
-----------------
etymology: the stody of words, and how they came to be
entomology: the study of insects, including those deemed bugs
... in computer science, we can have *both* in one subject!