zsh-users
 help / color / mirror / code / Atom feed
* Completion and double quotes
@ 2010-08-11 19:30 Joke de Buhr
  2010-08-11 21:51 ` Benjamin R. Haskell
  2010-08-12  9:31 ` Peter Stephenson
  0 siblings, 2 replies; 7+ messages in thread
From: Joke de Buhr @ 2010-08-11 19:30 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 706 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Completion and double quotes
  2010-08-11 19:30 Completion and double quotes Joke de Buhr
@ 2010-08-11 21:51 ` Benjamin R. Haskell
  2010-08-11 22:29   ` Joke de Buhr
  2010-08-12  9:31 ` Peter Stephenson
  1 sibling, 1 reply; 7+ messages in thread
From: Benjamin R. Haskell @ 2010-08-11 21:51 UTC (permalink / raw)
  To: Joke de Buhr; +Cc: zsh-users

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

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.)

-- 
Best,
Ben

[1] http://en.wikipedia.org/wiki/Leaning_toothpick_syndrome


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Completion and double quotes
  2010-08-11 21:51 ` Benjamin R. Haskell
@ 2010-08-11 22:29   ` Joke de Buhr
  0 siblings, 0 replies; 7+ messages in thread
From: Joke de Buhr @ 2010-08-11 22:29 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: Text/Plain, Size: 2092 bytes --]

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.)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 706 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Completion and double quotes
  2010-08-11 19:30 Completion and double quotes Joke de Buhr
  2010-08-11 21:51 ` Benjamin R. Haskell
@ 2010-08-12  9:31 ` Peter Stephenson
  2010-08-12 10:53   ` Joke de Buhr
  2010-08-12 15:57   ` Bart Schaefer
  1 sibling, 2 replies; 7+ messages in thread
From: Peter Stephenson @ 2010-08-12  9:31 UTC (permalink / raw)
  To: zsh-users

On Wed, 11 Aug 2010 21:30:08 +0200
Joke de Buhr <joke@seiken.de> wrote:
> 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.

It's not configurable, but you can put the double quote right at the start
of the filename and it probably does what you want.

The code for handling quoting in completion is utterly impenetrable.  It's
actually at it's worst when you're in a nested expression, for example inside:

  su -c 'ls /path/to/"file with"<TAB>

which is quite liable to crash the shell (I didn't dare try).  Even so,
it's bad enough even in the "simple" case that I don't think it's ever
going to be able to second guess intentions to the sort of level you want.
Of course, as always, if someone has a few dozen of hours of spare time and
wants to make it their life's work to improve, that's fine.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Completion and double quotes
  2010-08-12  9:31 ` Peter Stephenson
@ 2010-08-12 10:53   ` Joke de Buhr
  2010-08-12 11:03     ` Peter Stephenson
  2010-08-12 15:57   ` Bart Schaefer
  1 sibling, 1 reply; 7+ messages in thread
From: Joke de Buhr @ 2010-08-12 10:53 UTC (permalink / raw)
  To: zsh-users

[-- Attachment #1: Type: Text/Plain, Size: 1492 bytes --]

On Thursday 12 August 2010 11:31:26 Peter Stephenson wrote:
> On Wed, 11 Aug 2010 21:30:08 +0200
> 
> Joke de Buhr <joke@seiken.de> wrote:
> > 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.
> 
> It's not configurable, but you can put the double quote right at the start
> of the filename and it probably does what you want.
> 

If put the double quote right at the start is there any way to get the 
completion to work paths beginning with "~" ? My completion doesn't offer 
anything in these cases:

Example:
  ls "~/<TAB>    <-- no completion at all

Completion only works if the "~" is unquoted (like: ~"/<TAB>) but quotes later 
on are destroyed during that process.

> The code for handling quoting in completion is utterly impenetrable.  It's
> actually at it's worst when you're in a nested expression, for example
> inside:
> 
>   su -c 'ls /path/to/"file with"<TAB>
> 
> which is quite liable to crash the shell (I didn't dare try).  Even so,
> it's bad enough even in the "simple" case that I don't think it's ever
> going to be able to second guess intentions to the sort of level you want.
> Of course, as always, if someone has a few dozen of hours of spare time and
> wants to make it their life's work to improve, that's fine.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 706 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Completion and double quotes
  2010-08-12 10:53   ` Joke de Buhr
@ 2010-08-12 11:03     ` Peter Stephenson
  0 siblings, 0 replies; 7+ messages in thread
From: Peter Stephenson @ 2010-08-12 11:03 UTC (permalink / raw)
  To: zsh-users

On Thu, 12 Aug 2010 12:53:52 +0200
Joke de Buhr <joke@seiken.de> wrote:
> On Thursday 12 August 2010 11:31:26 Peter Stephenson wrote:
> > On Wed, 11 Aug 2010 21:30:08 +0200
> > 
> > Joke de Buhr <joke@seiken.de> wrote:
> > > 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.
> > 
> > It's not configurable, but you can put the double quote right at
> > the start of the filename and it probably does what you want.
> > 
> 
> If put the double quote right at the start is there any way to get
> the completion to work paths beginning with "~" ?

Interesting case, and I think you're stuck there.  Unless someone can see
an ingenious solution, the only way would be to expand the ~ first or use
variables.  You could semi-automate converting the ~ to something starting
"/home/blah with some shell function magic, but without grungy changes deep
in the completion code I think that's as good as it's going to get.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Completion and double quotes
  2010-08-12  9:31 ` Peter Stephenson
  2010-08-12 10:53   ` Joke de Buhr
@ 2010-08-12 15:57   ` Bart Schaefer
  1 sibling, 0 replies; 7+ messages in thread
From: Bart Schaefer @ 2010-08-12 15:57 UTC (permalink / raw)
  To: zsh-users

On Aug 12, 10:31am, Peter Stephenson wrote:
}
} The code for handling quoting in completion is utterly impenetrable.

To be both more and less specific, the code for handling just about
anything in _path_files is utterly impenetrable.

} It's actually at it's worst when you're in a nested expression, for
} example inside:
} 
}   su -c 'ls /path/to/"file with"<TAB>
} 
} which is quite liable to crash the shell (I didn't dare try).

That may be a slight exaggeration:

schaefer<501> su -c 'ls /home/schaefer/Desktop/Camera\ Dump\ 2010-08-07/
Completing corrections
Camera\ Dump\ 2010-08-07/  Camera\ Dump\ 2010-01-24/
Camera\ Dump\ 2010-03-19/  Camera\ Dump\ 2009-12-31/
Camera\ Dump\ 2010-02-06/  Camera\ Dump\ 2007-08-13/
Camera\ Dump\ 2010-01-30/                           
Completing original
ls /home/schaefer/Desktop/"Camera Dump"

} Even so, it's bad enough even in the "simple" case that I don't think
} it's ever going to be able to second guess intentions to the sort of
} level you want.

The guessing problem could be solved just by keeping the original quoting,
but of course it's not that simple -- in order to decide what to match,
the quoting has to be removed/canonicalized internally, and in the most
general case it's then difficult if not impossible to figure out what
part of the completed string corresponds to the quoted portion of the
original string.  Remember, zsh completion can insert characters almost
anywhere (or even replace the entire original string with something that
doesn't resemble it at all), not merely append at the end.

With regard to putting the quote before the tilde ... that's not going
to work, because unless zsh expanded the tilde before completing, the
resulting word will still have a quoted tilde in it, which in turn will
not be expanded when the command is eventually executed.  Not often
what you want, I suspect.

You may be able to create a wrapper widget along the lines of
Functions/Zle/quote-and-complete-word that restores a more palatable
quoting after completion has finished.


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-08-12 16:58 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-11 19:30 Completion and double quotes Joke de Buhr
2010-08-11 21:51 ` Benjamin R. Haskell
2010-08-11 22:29   ` Joke de Buhr
2010-08-12  9:31 ` Peter Stephenson
2010-08-12 10:53   ` Joke de Buhr
2010-08-12 11:03     ` Peter Stephenson
2010-08-12 15:57   ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).