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

[Klaus Weide]

On Tue, 11 Apr 2000, Vlad Harchev wrote:
> On Mon, 10 Apr 2000, Klaus Weide wrote:
> > I have to admit I forgot (or never understood) why Henry finds this as
> > important as he does.
> 
>    Me too. 

Maybe he could remind us once more.

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

They are already allowed, options with unusual values (that don't fit
your "in most cases") already exist - not just SUFFIX_ORDER.

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

Not much different from all the FOO:a:b and FOO:a:b:c and FOO:a:b:c:d that
already exist.  Come on, this isn't much extra work.

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

They configure apsects of the "source cache".  Tee option is named
SOURCE_CACHE, not just SOURCE_CACHE_KIND_OF_STORAGE or the like, ergo
it's most logical that aspects of the "source cache" are configured
with this option.  (That's *my* main reason why I would prefer this
to be covered by SOURCE_CACHE.)

> And as for SUFFIX_ORDER - there are a few allowed values for it, 

1- same here.
2- the number of flags could grow.

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

I have no problem with the number 0.
I do have problems with increasing the number to 1, if that means that
it's suddenly more important that lynx.cfg is parseable by machines
than by humans.

If I understand right what you are doing, you already need lots of
option-specific validator functions for the existing options.  Just as
there are lots of options which have (in LYReadCFG.c) CONF_FUN instead
of CONF_BOOL etc.

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

There a xx thousands of users, on the one hand.  There is (maybe) one
configuration tool for which one person must write an additional function
or two, on the other hand.  Guess whose life I'd prefer to make a bit
easier, if there is really such a choice to make.

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

So you are writing a configuration tool that works only for some options?
Only for those you expect not to be changed "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 repeat, I find that would introduce ugliness without real benefit.

   Klaus