Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH

[Klaus Weide]

On Tue, 20 Apr 1999, Vlad Harchev wrote:
> On Sun, 25 Apr 1999, Klaus Weide wrote:
> 
> > 3) Choose a different syntax, with a different delimiter!
> > There are bound to be problems with ':' not matter how cleverly
> > you try to detect which ':' is part of a filename and which isn't.
> > 
> > The delimiter should be unlikely to normally occur in filenames on
> > any known system.  It can still be a legal (but unusual) filename
> > character, in that case files with that character just cannot be
> > used here - not a big hardship.  That's better than introducing
> > an escape mechanism (which would create more confusion).
> 
>  Probably that character should be '*'? What lynx developers think about it
> (suggestions of characters are welcome)

I don't like '*', since it usually means something else when filenames are
concerned.  Many other characters can legitimately appear in filenames,
and are used by some folks.  '|' kinda looks like a good separator, but
it implies the wrong thing (and would be natural to reserve if anybody
ever thinks of making lynx read from command pipes instead of files; see
Perl's open() syntax).

Why not use just ' ' space?   Apart from disallowing filenames with
spaces, it looks non-intuitive, as if several files were included.

Actually, in *this* case (not generally), I'm in favor of adding some
syntactic sugar.  As in

  include:~/.lynx/rc for COLOR KEYMAP VIEWER SUFFIX

with 'for' as a reserved special word.  That makes it quite obvious
what the extended syntax means.  To allow (unambiguouly) filenames
with spaces, some sort of quoting (with '"'?) should also be recognized
(but that's ugly because in quoted strings I'd expect '\' to act like
an escape, which intereferes with usage as path separator on Windows
where filenames with spaces are most likely to occur).

>  Another idea - seems that ':' is unusual character in unix filenames - so we
> can support this feature on unix as it is (without changing extra logic like
> quoting, escaping, etc - just ifdef'ing), and disable it on DOS,VMS, MacOS - I
> don't think there are a lot of ISP that run these OSes.

Why introduce a new feature, potentially useful beyond the situation
you envision ('ISP'), and then artificially restrict it (not for
functional reasons)?

>  Or we can provide this feature on these OSes, but delimiter will be different
> from ':' for them - may be '*' on these OSes and still ':' on unix?

There's already too many "if your OS is x, then do this, but if your OS is y
then do that" things to confuse people, many of them undocumented.  Please
don't add more unless necessary.

    Klaus