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

[Klaus Weide]

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.

> 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).

> 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

>  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.
2.) So the case you'll find with egrep broke some external tool?  I don't
    think so.  I didn't hear you complain.
    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.

>  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.

>  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.

   Klaus