[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
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, dickey, 1999/04/23
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Vlad Harchev, 1999/04/24
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Klaus Weide, 1999/04/25
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Vlad Harchev, 1999/04/25
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Klaus Weide, 1999/04/25
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH,
Vlad Harchev <=
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Vlad Harchev, 1999/04/26
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Klaus Weide, 1999/04/26
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Vlad Harchev, 1999/04/26
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Leonid Pauzner, 1999/04/26
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Vlad Harchev, 1999/04/27
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Leonid Pauzner, 1999/04/26
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Vlad Harchev, 1999/04/26
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Leonid Pauzner, 1999/04/27
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Vlad Harchev, 1999/04/28
- Re: lynx-dev dev.23: extended INCLUDE syntax broken for DOSPATH, Doug Kaufman, 1999/04/28