Comment 19 for bug 613153

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:

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