I like this a lot. I speculate that odd file names come from folks
using GUIs who aren't aware of what the conventions are in a shell - I
remember an AppleShare to NFS appliance I dealt with that had to do
magic for the Mac folks who liked to name their files " - report of
3/2/1990 - ". Once it embedded a null within the file name. Shudder.
I am reluctant, however, to innovate with @root, and leave @path and
@<file> (i.e., every external file directive other than @root) doing
something different. Does anyone use
@path < file name with surrounding angle brackets and outside spaces
stripped (but no other characters)? >
Google probably wrapped that, and an opening < " or ' without the
corresponding close character before the newline throws an error, but
I think you understand what I meant. Newline and carriage return are
a valid characters in a Unix file name, but are reserved to
sadomasochists ;-).
- Stephen
On Jun 8, 10:01 am, Terry Brown <[email protected]> wrote:
> On Mon, 7 Jun 2010 17:59:26 -0700 (PDT)
>
>
>
> thyrsus <[email protected]> wrote:
> > In @root arguments (which become the last component of the file name),
> > the tangle.setRootFromText() method iremoves surrounding character
> > pairs <> and "", but not '', then removes any leading and trailing
> > whitespace.
>
> > In @path arguments, the the g.stripPathCruft() method removes
> > character pairs <>, "", and '', then removes any leading and trailing
> > whitespace.
>
> > I urge that the behavior be made consistent.
>
> > Which way should it go?
>
> > Since @root is much less used than @path, there's a strong argument
> > for using the @path convention.
>
> > Were I designing things from the beginning, I'd give a function to the
> > quoting characters pairs that they suppress the leading and trailing
> > whitespace removal - if you want whitespace removal from around the
> > file name, don't quote it!
>
> Am I understanding, that would allow you to create (or load, I guess), files
> with leading or trailing spaces in their names?
>
> Hmm, on the one hand, why would you ever want to do that, on the other, we'd
> want Leo to be able to edit files with any valid filename, even a really odd
> one.
>
> Seems to me the simplest thing (sort of starting from scratch) would be to
> allow either a naked filename (leading/trailing whitespace stripped), or a
> subset of python string representations, i.e. if, after the initial
> whitespace stripping, first and last character are "'" or '"', one level of
> such characters would be stripped, and the result used, regardless of further
> leading or trailing whitespace, and regardless of further characters from the
> set ['"><].
>
> Cheers -Terry
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en.
