On Wednesday 11 August 2010 23:51:24 Benjamin R. Haskell wrote:
> On Wed, 11 Aug 2010, Joke de Buhr wrote:
> > Hi,
> > 
> > Currently my completion is somehow configured to transform double
> > quoted paths to backslash escaped paths.
> > 
> > Example:
> >   ls /path/to/"file with"<TAB> -> /path/to/file\ with\ spaces
> > 
> > I would like the completion not to touch the quotation. But I can't
> > figure out how to get zsh to do this. The completion should work like
> > this.
> > 
> > Example:
> >   ls /path/to/"file with"<TAB> -> /path/to/"file with spaces"
> > 
> > I don't remember what completion options caused the current behavior
> > but I remember having zsh configured to not touch the quotes.
> 
> Are you sure your above example worked before?  It's always bugged me a
> little (but not enough to search for it) that zsh leaves:
> 
> "/path/to/file with<Tab>
> as a quoted string:
> "/path/to/file with spaces"
> 
> but:
> /path/to/"file with<Tab>
> becomes toothpicked[1]:
> /path/to/file\ with\ spaces

It's been a while since I reconfigured the completion so maybe I got confused. 
Maybe only a fully quoted path stayed quoted before.

But it would be really useful if the completion would stay quoted because the 
completion doesn't work if the fully quoted path starts with "~/" path. At 
least with my current configuration zsh doesn't offer any possible completion 
in this cases.

Example:
  "~/any/existing/path<TAB>  <-- no completion offered

> So, I'd also be interested to know what I'm overlooking.
> 
> A similar thing that bothers me is the way named directories are
> somewhat inconsistently expanded.  (From my perspective, that is.  It's
> probably entirely internally consistent.)  I can't come up with a
> minimal example right now, but I notice it most when trying to do things
> like:
> 
> for l in ~/bin/{*.pl,<Tab>
> 
> (That is: combinations of bracket expansion and file completion.)
> 
> Perhaps the cure(s) are the same or similar?  (Wouldn't be surprised if
> the latter weren't curable.)