Comment 20 for bug 613153

On Sat, 14 Aug 2010 11:39:19 -0000
"Edward K. Ream" <email address hidden> wrote:

> On Thu, Aug 5, 2010 at 6:01 PM, tbnorth <email address hidden> wrote:
> > Edward, not sure if you're following this thread,
>
> I have, but not closely.
>
> > but the fix turned out
> > to be entangled with a lot of @<file> stuff, so I don't want to push it
> > without your inspection.
>
> Thanks. Please don't commit *any* change to Leo's @path logic without
> consulting me first.
>
> > Repeating the basic problem: for an @<file> node there is some parent
> > path in effect at the point where you reach the node, based on the
> > location of the .leo file and any relevant @path directives.  For
> > determination of the full path to the target file, the @<file> node can
> > either extend the parent path with a relative path (simplest case, just
> > the filename), or discard the parent path with an absolute path of its
> > own.  The problem arises when the @<file> introduces a Windows drive
> > specific \absolute\path without specifying the drive.  In that case the
> > drive should come from the original parent path.
>
> Yuck. @path handling is extremely complex, and can't be made all that
> simple.
>
> > I think the diff below does that ok.  It might do it in more places than
> > was needed to fix the original problem, but I don't think it does it in
> > any places where it shouldn't.
>
> I don't like this solution. The only clean place to handle this
> difficult detail is in the g.os_path_xxx methods, including
> g.os_path_finalize_join. These functions exist for two important
> reasons:

I think the problem with fixing it there is that the paths in questions (paths starting with a single backslash on Windows) can't be resolved without knowing what the "current drive" is, and that can only be known by knowing the directory in effect (as a result of any @paths) at the @<file> node in question.

More clearly :-} - Leo switches program flow on the basis of os.path.isabs(), but os.path.isabs() gives a bogus result for paths starting with a single backslash on Windows. Aha! :-) Maybe that's how the fix can be pushed into g.os_path_xxx, we just need a g.os_path_isabs which knows such paths are really relative, and to make sure the other g.os_path_xxx handle the joins correctly. I was thinking it couldn't be handled in g.os_path_xxx because you lose the leo-current-directory context by the time you're there, but that's only when os.path.isabs() is giving a wrong answer.

I'll re-visit the changes needed taking that approach.

Cheers -Terry

> 1. To ensure that Leo handles unicode properly in file names and
>
> 2. To handle the kind of details we have here.
>
> Please focus any fix on these functions. If it turns out that some
> code doesn't call these methods, but should, then *that* is the place
> to make fixes outside leoGlobals.py.
>
> Perhaps I am misunderstanding your intention. It's fine with me if
> g.fix_windows_absolute is a helper for the g.os_path functions, but I
> do not want special-purpose hacks being added outside of leoGlobals.py
> unless that is absolutely necessary.
>
> Edward
>