complete paths after non-space

complete paths after non-space

[Deliverable Mail]

I'm migrating to zsh and find it differs subtly from bash.  Three
immediate look-'n-feel diffs I'd really need to reset to
bash-compatible behavior...

1.  completing path names with leading non-space

I often want to complete filenames in options where you have things
like --file=/wrong/path/name, whereby you go back and fix it, or enter
new things after the non-space-starting pathname sequence

Bash happily completed it while in my current zsh setup I have to
insert/delete a space prior to the pathname.  An easy way to make it
the same?

2.  in-place ^r search

-- zsh offers an underline, and I don't want it

3.  completion offers must go away faster

-- zsh lists them in the underline(s) and they seem to linger there
longer than in bash, can I banish them faster?

Cheers,
Alexy

Re: complete paths after non-space

[Deliverable Mail]

Here's an example.  If you want to give a pathname to tar with
--files-from=/path/name, bash will complete the /path/name for you,
even though it's immediately after the '=', while zsh, as configured
by default on my box, will not -- I need to go between = and /path and
insert a space, then go to the end and press tab to complete
/path/name, then return to '= /' and remove the space.  Which settings
control zsh behavior in this case -- tokenization, special flag(s)?

Alexy

On 8/2/05, Deliverable Mail <deliverable@gmail.com> wrote:
> I'm migrating to zsh and find it differs subtly from bash.  Three
> immediate look-'n-feel diffs I'd really need to reset to
> bash-compatible behavior...
> 
> 1.  completing path names with leading non-space
> 
> I often want to complete filenames in options where you have things
> like --file=/wrong/path/name, whereby you go back and fix it, or enter
> new things after the non-space-starting pathname sequence
> 
> Bash happily completed it while in my current zsh setup I have to
> insert/delete a space prior to the pathname.  An easy way to make it
> the same?
> 
> 2.  in-place ^r search
> 
> -- zsh offers an underline, and I don't want it
> 
> 3.  completion offers must go away faster
> 
> -- zsh lists them in the underline(s) and they seem to linger there
> longer than in bash, can I banish them faster?
> 
> Cheers,
> Alexy
>

Re: complete paths after non-space

[Philippe Troin]

setopt magicequalsubst

Phil.

Deliverable Mail <deliverable@gmail.com> writes:

> Here's an example.  If you want to give a pathname to tar with
> --files-from=/path/name, bash will complete the /path/name for you,
> even though it's immediately after the '=', while zsh, as configured
> by default on my box, will not -- I need to go between = and /path and
> insert a space, then go to the end and press tab to complete
> /path/name, then return to '= /' and remove the space.  Which settings
> control zsh behavior in this case -- tokenization, special flag(s)?
> 
> Alexy
> 
> On 8/2/05, Deliverable Mail <deliverable@gmail.com> wrote:
> > I'm migrating to zsh and find it differs subtly from bash.  Three
> > immediate look-'n-feel diffs I'd really need to reset to
> > bash-compatible behavior...
> > 
> > 1.  completing path names with leading non-space
> > 
> > I often want to complete filenames in options where you have things
> > like --file=/wrong/path/name, whereby you go back and fix it, or enter
> > new things after the non-space-starting pathname sequence
> > 
> > Bash happily completed it while in my current zsh setup I have to
> > insert/delete a space prior to the pathname.  An easy way to make it
> > the same?
> > 
> > 2.  in-place ^r search
> > 
> > -- zsh offers an underline, and I don't want it
> > 
> > 3.  completion offers must go away faster
> > 
> > -- zsh lists them in the underline(s) and they seem to linger there
> > longer than in bash, can I banish them faster?
> > 
> > Cheers,
> > Alexy
> >

Re: complete paths after non-space

[Peter Stephenson]

Deliverable Mail wrote:
> I'm migrating to zsh and find it differs subtly from bash.  Three
> immediate look-'n-feel diffs I'd really need to reset to
> bash-compatible behavior...
> 
> 1.  completing path names with leading non-space
> 
> I often want to complete filenames in options where you have things
> like --file=/wrong/path/name, whereby you go back and fix it, or enter
> new things after the non-space-starting pathname sequence
> 
> Bash happily completed it while in my current zsh setup I have to
> insert/delete a space prior to the pathname.  An easy way to make it
> the same?

If you're using the new completion system (compinit), turn on the option
magicequalsubst.

  setopt magicequalsubst

(It's just possible it works with the old completion system, too.)

> 2.  in-place ^r search
> 
> -- zsh offers an underline, and I don't want it

You just have to ignore it.   It's unusual enough not to want to see
what your searching for that there's no option.

> 3.  completion offers must go away faster
> 
> -- zsh lists them in the underline(s) and they seem to linger there
> longer than in bash, can I banish them faster?

It's possible you can do something with zle -R in one of the completion
functions, which redisplays the stuff below the line using the string
you specify (which might be empty), but I've never played around with this.

You can force the shell to reprint the line below all completion
displays by

  unsetopt alwayslastprompt

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


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: complete paths after non-space

[Deliverable Mail]

Apparently setopt magicequalsubst doesn't work by itself -- so I infer
I'm not using compinit.  How do I make sure I use it?

Also for in-line ^r, bash's behavior is quite normal -- the command
appears at the prompt.  zsh shows the pattern under the line as well.
I don't need that down-and-up, as I can see the pattern right in the
line.  Perhaps I'm overoptimistic, but if zsh is the superheroes'
shell, it should be anything bash can be and beyond!  If some people
can't remember two-three chars they just typed in, and they're in
denial of their ADHD, perhaps the pattern can be highlighted.  Same
goes for opening a bunch of stuff for completion under the line -- the
'feel' discomfort coming from bash is that you have "stuff" under the
prompt line, like a wet basement, and in bash you pretty much feel the
solid cement floor of the prompt.  It's not jerking up-and-down
suddenly.  I'm using zsh in a quake-prone area, and it shows :-)...

Cheers,
Alexy

On 8/3/05, Peter Stephenson <pws@csr.com> wrote:
> Deliverable Mail wrote:
> > I'm migrating to zsh and find it differs subtly from bash.  Three
> > immediate look-'n-feel diffs I'd really need to reset to
> > bash-compatible behavior...
> >
> > 1.  completing path names with leading non-space
> >
> > I often want to complete filenames in options where you have things
> > like --file=/wrong/path/name, whereby you go back and fix it, or enter
> > new things after the non-space-starting pathname sequence
> >
> > Bash happily completed it while in my current zsh setup I have to
> > insert/delete a space prior to the pathname.  An easy way to make it
> > the same?
> 
> If you're using the new completion system (compinit), turn on the option
> magicequalsubst.
> 
>  setopt magicequalsubst
> 
> (It's just possible it works with the old completion system, too.)
> 
> > 2.  in-place ^r search
> >
> > -- zsh offers an underline, and I don't want it
> 
> You just have to ignore it.   It's unusual enough not to want to see
> what your searching for that there's no option.
> 
> > 3.  completion offers must go away faster
> >
> > -- zsh lists them in the underline(s) and they seem to linger there
> > longer than in bash, can I banish them faster?
> 
> It's possible you can do something with zle -R in one of the completion
> functions, which redisplays the stuff below the line using the string
> you specify (which might be empty), but I've never played around with this.
> 
> You can force the shell to reprint the line below all completion
> displays by
> 
>  unsetopt alwayslastprompt
> 
> --
> Peter Stephenson <pws@csr.com> [...]

Re: complete paths after non-space

[Wayne Davison]

On Wed, Aug 03, 2005 at 04:24:12PM -0700, Deliverable Mail wrote:
> Also for in-line ^r, bash's behavior is quite normal

I consider bash's solution sub-optimal -- replacing the command-prompt
with the search prompt (which tends to bump the line over one direction
or another) and then continuing to slide the line around for every
character typed -- it just seems much nicer to me to put the prompt down
below (which is also more like it would be in an actual Emacs editor).

> Same goes for opening a bunch of stuff for completion under the line

Yes, exactly the same.  :-)  What I like about the zsh way is that the
completion items don't get left to clutter the screen after you're done
creating the command.  With bash, you can end up scrolling all the prior
output off the screen after just a few completion listings, whereas zsh
continues to update the completions under the prompt, and then removes
them when it is all done.  Of course, you can choose to turn this off
via "unsetopt alwayslastprompt", but I'd suggest giving the zsh way a
chance first -- I think you're experiencing a natural "that's not the
way I'm used to it working" reaction, but if you give it some time, you
may discover you like the zsh way better.

..wayne..

Re: complete paths after non-space

[Deliverable Mail]

It also appears that zsh by default does not conmplete path elements in

export PATH=/path/one:/pa<TAB> ... -- nothing

are colons covered by magicequalsubst ?  Even with compinit, my zsh
4.0.2 does not complete after = or :...   How do I tell zsh to
tokenize on = and :, and possibly something else?

Alexy

Re: complete paths after non-space

[Mikael Magnusson]

On 8/5/05, Deliverable Mail <deliverable@gmail.com> wrote:
> It also appears that zsh by default does not conmplete path elements in
> 
> export PATH=/path/one:/pa<TAB> ... -- nothing
> 
> are colons covered by magicequalsubst ?  Even with compinit, my zsh
> 4.0.2 does not complete after = or :...   How do I tell zsh to
> tokenize on = and :, and possibly something else?

20010627 : Release 4.0.2
I don't remember you mentioning you using that semi-arcane version
previously in this thread, maybe you should try the latest version
first?

> Alexy
> 


-- 
Mikael Magnusson

Re: complete paths after non-space

[Deliverable Mail]

Got 4.2.5, setopt magicequalsubst, pathname completion works after =,
but not after : in a PATH.  Is there another option governing colons?

Alexy

On 8/5/05, Peter Stephenson <pws@csr.com> wrote:
> Deliverable Mail wrote:
> > Do compinit, then setopt magicequalsubst, then tar
> > --files-from=3D/ho<TAB>, blinks but not completes /home.  I have zsh
> > version 4.0.2, is it good enough?...
> 
> I can't remember, 4.0.2 is rather old.  You probably want to try the
> 4.2 series.
> 
> PATH=...:... completion should also work.
> 
> pws
> 
> 
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
> 
> **********************************************************************
> 
>

Re: complete paths after non-space

[Peter Stephenson]

Deliverable Mail wrote:
> Got 4.2.5, setopt magicequalsubst, pathname completion works after =3D,
> but not after : in a PATH.  Is there another option governing colons?

I don't think so.  It works for me anywhere the shell finds
  [anything]=[anything]:[stuff]

Run C-x ?, go up a line and look at the debug output
file.  It should contain a (rather arbitrarily extracted) bit like:

+_dispatch:62> [[ '' != '(all|*patterns*)' ]]
+_dispatch:63> str=-value-,PATH,-default-
+_dispatch:64> [[ -n -value-,PATH,-default- ]]
+_dispatch:65> service=-value-,PATH,-default- 
+_dispatch:66> i=_dir_list
+_dispatch:67> _compskip=default 
+_dispatch:68> eval _dir_list
+(eval):1> _dir_list
+_dir_list:10> local 'sep=:' dosuf suf
+_dir_list:12> [[ '' == '-(s*|S)' ]]
+_dir_list:20> compset -P '*:'
+_dir_list:21> compset -S ':*'
+_dir_list:21> suf=: 
+_dir_list:23> [[ -n '' ]]
+_dir_list:26> suf=( ) 
+_dir_list:29> _directories -r ': /\t\t\-'

The compset's are the key to stripping off the parts of the colon path
that aren't wanted.

If it's never getting into _dir_list, see what's happening when
it enters _value (that handles completion for values of parameters
or anything that looks like one).  It should be getting there if
magic_equal_subst is having its effect.


pws


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************