lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vlad Harchev
Subject: Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH
Date: Tue, 20 Apr 1999 23:12:23 +0500 (SAMST)

On Sun, 25 Apr 1999, Klaus Weide wrote:

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

 Yes, may be '*' will be confusing - since it should be right after file name,
like in
 include:~/.lynx/rc* COLOR VIEWER
 - some people may think that lynx includes all files matching shell
pattern "rc*". 
 May be we should impose a restriction, that there must be at least one ' '
before ':' - and this solves problems for all OSes, as in

 include:c:\lynx\mylynx.cfg :COLOR VIEWER

 We can make a following rule: only first ' ' before ':' will be removed -
to get a file name - this will allow the use of filenames terminating with
space.

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

  IMO, implementation of  this "sugar" won't be obvious, and this will be
inconsistent with syntax of other lynx options.

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

 If this is a way of fixing bug, it should be considered if the bug (that
appears only in those environments) is severe or providing support for those
(not widely spread) environments requires a lot of work. (As color styles
 with slang)
  But our case is different from this, I agree.
  And I listed removing this feature for those OSes as alternative (one of
several), waiting for opinions of other lynx developers.

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

 Best regards,
  -Vlad


reply via email to

[Prev in Thread] Current Thread [Next in Thread]