Re: lynx-dev SOURCE_CACHE "problem" - proposal of SOURCE_CACHE_FOR_INCOMPLETE

[Vlad Harchev]

On Mon, 10 Apr 2000, Klaus Weide wrote:

> On Mon, 10 Apr 2000, Vlad Harchev wrote:
> 
> >  As for sub-options in lynx.cfg - I think that 
> > 1) Complication of code that parses suboptions in a way Klaus propsed, e.g.
> >    FOO:A,B - is totally unnecessary compared to the net effect it gives - 
> >    just getting rid of new toplevel option.
> 
> I have to admit I forgot (or never understood) why Henry finds this as
> important as he does.

   Me too. 

> > 2) Complicating the syntax makes the use of various scripts and tools
> >    that edit or parse lynx.cfg very complicated and impossible.
> 
> All you can rely on with *existing* options is that they have the form:
>    <OPTION_NAME> ':' <content completely specific to the option>
> with only certain characters allowed in <OPTION_NAME>, and some minimal
> rules about the right side (like: there can't be newline chars).

   If values of the form 'FOO:A,B' are not used, then in most cases I can
assume that changing the string to the right of FOO changes the value. Also
for most options it's possible to enumerate allowed values (i.e. no regexp is 
necessary - just a list of allowed strings). If values
of the form FOO:A,B are allowed, then when writing configuration tool, I have
to keep in mind that user can change only the part of the metavalue (change A
to C) so the right part should modified in some way to reflect change of A to 
C. This is unnecessary complication.
 
> > 3) Hiding several suboptions under one toplevel option decreases the
> >    flexibility of extended INCLUDE syntax.
> > 4) This is the first precedent of complicating things in that way (FOO:A,B) 
> > - 
> >    suboptions were implemented as FOO:A:V1 and FOO:B:V2 before. I don't want
> >    to make the broken syntax as FOO:A,B normal.
> 
> No, it isn't the first time.  Try
> 
>    egrep '[A-Z_]+:[A-Z_]+,[A-Z_]+' lynx.cfg

  Only SUFFIX_ORDER matches this pattern. I don't think that this setting is
as important as SOURCE_CACHE is. The probability of user wishing to change
SOURCE_CACHE related things is (IMO) by several orders higher than the one
wishing to change SUFFIX_ORDER. The values between commans of SUFFIX_ORDER
configure one thing, while the variant you propose configure rather different
things.
And as for SUFFIX_ORDER - there are a few allowed values for it, so each 
combination can be given another name without comma in it.
  In fact, I've written configurator for lynx for DOS. Current option naming
scheme allows to use table-based approach (option name, description,
validator function) for it, various (unnecessary) complications will result in
fewer (in theory) configuration tools for lynx.cfg. 

> >  As for pride in my work - I'd better spend time on hacking some other Open
> > Source project (a lot needs hacking alas) rather than turning the syntax of
> > lynx.cfg in completely unparsable by external tools.
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 1.) Human readers should matter more than some hypothetical external tools.

        human readers are easily configurable :)

> 2.) So the case you'll find with egrep broke some external tool?  I don't
>     think so.  I didn't hear you complain.

        I just don't want to give a real precedent (so I care about the
future, not the only about SOURCE_CACHE).

>     The existing options all have their own syntax rules already, anyway.
>     For example, in some URL- or file-like options backslash is interpreted
>     as an escape and in others not, sometimes whitespace is significant, etc.

        How often do you expect user will change them? I don't think very
often.

> >  I already proposed an approach to naming options - they should contain dots
> > and thus lynx.cfg will look like X resources file, e.g.:
> 
> ...and be just as confusing to the average person.

  Probably. But only you replied to that proposal (may be others have
different opinions).

> >  I state that I will implement only toplevel option for this feature (no
> > suboptions for this). It's up to Tom to (not)include/edit the patch I will
> > submit. 
> 
> Please reconsider.

  I won't reconsider.
 
>    Klaus
> 

 Best regards,
  -Vlad