Re: Another _path_files bug?

[Bart Schaefer <schaefer@brasslantern.com>]

On Feb 11,  8:39pm, Peter Stephenson wrote:
} Subject: Re: Another _path_files bug?
}
} On Thu, 10 Feb 2011 09:28:20 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > }
} > } torch% setopt completeinword
} > } torch% ls Test/
}                ^completing here...
} > } torch% ls Test//Test/Makefile
} > 
} >     compadd -Qf -J -default- -J -default- -p Test/ \
} >             -s /Makefile -W Test// -M 'r:|/=* r:|=*' - Test
} 
} This is more an experiment than a suggested fix, but I wonder if the
} problem is it's assuming there are three path sections: an initial path,
} the middle bit, that the cursor's in the middle of, and then contents of
} the directory at the end.  In the case here, we've only got two: the
} "Test/" is being treated as both the initial part and the middle part.

Yes, that does seem to describe the situation.

} So if we add a separate case for handling this it improves things.

This works for the test cases I could think of applying, such as putting
a full path at the front and (separately) where the tail is ambiguous.
 
} Obvious we'll need to find out if the original problem was more general,
} in which case splitting off this case may work but isn't the right fix,
} or if this has repercussions in other simple cases.

I haven't found any that break, but I don't have, e.g., any files with
multibyte characters in their names handy to try.

} Also, what does the 'if [[ -z "$tmp4" ]]' just above that signify?  I
} think (from the comment above 729) it might just mean we've finished
} collecting things and are about to add them to the completion ---

That's must be essentially correct -- when tmp4 is non-empty we go back
to the top of "for prepath in ..." at line 350, otherwise we enter this
block and (eventually) do one of "for i in "$tmp1[@]" ..." to add each
string from tmp1 individually, or "compadd ... -a tmp1" to add them all
at once.

In other cases, though, we compadd the contents of tmp1 in the body of
the "while true;" loop from line 595.  See comment at 597.  At the point
where tmp4 becomes empty, tmp1=( Makefile ) [the sole completion in the
Test subdir] so empty tmp4 appears to signify that we have in fact NOT
found a real file matching the current component (the current component
in this instance is the empty path tail after "Test/").