two completion questions

two completion questions

[Andy Spiegl]

Hi!

I switched to zsh a few month ago and I like it better every day!

There are just two annoying things:

When completing filenames that start with the same prefix which I have
typed already, zsh doesn't show me the other possibilities.  It's a bit
difficult to explain.  I'll better show you an example:

 hamster:/tmp/zsh>ls -l
 total 0
 -rw-r-----   1 spiegl   users           0 Dec 10 18:16 a
 -rw-r-----   1 spiegl   users           0 Dec 10 18:16 ab
 -rw-r-----   1 spiegl   users           0 Dec 10 18:16 abc
 hamster:/tmp/zsh>ls -l

Now:  (cursor position at "_")
 hamster:/tmp/zsh>cat a_<TAB>
leads to
 hamster:/tmp/zsh>cat a _

However I would expect zsh to do this:
 hamster:/tmp/zsh>cat a_
 file
 a     ab    abc 

Maybe there is a switch I missed?


The other problem is that zsh doesn't append a / after .. although it's a
directory.  Here's an example again:
 hamster:/tmp/zsh>cd .._<TAB>
This just beeps instead of leading to this:
 hamster:/tmp/zsh>cd ../_


Actually this just reminded me of a third annoyance. :-)
zsh removes a (previously completed) / or a space in the middle of the
input line after C-e or C-a.  Example again:
 hamster:/tmp>echo ab_       (then I go back two columns...)
 hamster:/tmp>echo _ab       (...insert a directory...)
 hamster:/tmp>echo zs_ab     (...press TAB...)
 hamster:/tmp>echo zsh/_ab   (...now Ctrl-E to go to the end of line...)
 hamster:/tmp>echo zshab_

...and zsh removed the slash. :-(
The same happens if I let zsh not only complete the directory but a file.
The appended space is removed as soon as I move the cursor.

Off course "unsetopt AUTO_REMOVE_SLASH" removes this behavior, but then the 
slash is never removed.  I would expect zsh to remove the slash/space only
if there is no character below (or to the right of) the cursor.  Am I wrong? 

But otherwise I really love zsh!  Thanks for the great work!!!
 Andy.
-- 
 E-Mail: Andy@spiegl.de     URL: http://andy.spiegl.de
 PGP/GPG: see headers
                                o      _     _         _
  --------- __o       __o      /\_   _ \\o  (_)\__/o  (_)
  ------- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/
  ------ (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 This is a message from God: "Rebooting the universe, please log off." 

Re: two completion questions

[Bart Schaefer]

On Dec 10,  6:40pm, Andy Spiegl wrote:
} Subject: two completion questions
}
} Now:  (cursor position at "_")
}  hamster:/tmp/zsh>cat a_<TAB>
} leads to
}  hamster:/tmp/zsh>cat a _
} 
} However I would expect zsh to do this:
}  hamster:/tmp/zsh>cat a_
}  file
}  a     ab    abc 
} 
} Maybe there is a switch I missed?

It would appear that you have "setopt REC_EXACT".  With that set, zsh
accepts immediately any prefix that exactly matches an existing file,
even if there are longer names that also match.

} The other problem is that zsh doesn't append a / after .. although it's a
} directory.  Here's an example again:
}  hamster:/tmp/zsh>cd .._<TAB>
} This just beeps instead of leading to this:
}  hamster:/tmp/zsh>cd ../_

I'm not precisely sure why zsh handles ".." that way.  You can fix this
with compctl completion as follows:

	compctl -D -f + -g .. -S / -q

If you're using the new function-based completion in 3.1.6, it's going to
require some editing of the _path_files completer.  Hey, Sven, do you (or
any other zsh-workers) remember the rationale for this handling of ".."?

} Actually this just reminded me of a third annoyance. :-)
} zsh removes a (previously completed) / or a space in the middle of the
} input line after C-e or C-a.

That's because you're using expand-or-complete-prefix.  (Which you must
be, or else this ...

}  hamster:/tmp>echo zs_ab     (...press TAB...)
}  hamster:/tmp>echo zsh/_ab   (...now Ctrl-E to go to the end of line...)

... would not happen at all; you'd just get a feep.)

With expand-or-complete-prefix, the stuff to the right of the cursor is
not considered to be part of the result of the completion, so as far as
zsh can tell when you follow the completion with a cursor motion rather
than an character insertion it means you didn't want the slash.

} Off course "unsetopt AUTO_REMOVE_SLASH" removes this behavior, but
} then the slash is never removed. I would expect zsh to remove the
} slash/space only if there is no character below (or to the right of)
} the cursor. Am I wrong?

Autoremoval is not based on what's on the line, it's based on what the
next action is.  Essentially, insertions cause it to remain (unless the
inserted character is the same as the suffix) and anything else causes
it to be removed.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: two completion questions

[Zefram]

Bart Schaefer wrote:
>If you're using the new function-based completion in 3.1.6, it's going to
>require some editing of the _path_files completer.  Hey, Sven, do you (or
>any other zsh-workers) remember the rationale for this handling of ".."?

Globbing and completion never generate "." or ".." components; they are
filtered out in zreaddir().  The reason for this is that they are pretty
much never what you want.  If you have files named ".foo" and ".bar",
then type "." and press tab, are "." and ".." really what you want to
complete to?  Maybe there should be an option to complete to "." and
".." just like normal filenames, but I think the default should very
definitely stay as being the current behaviour.

-zefram

Re: two completion questions

[Andy Spiegl]

Hi Bart!

> It would appear that you have "setopt REC_EXACT".
Oops, you are so right.  Who put that in .zshrc? :-)

> I'm not precisely sure why zsh handles ".." that way.  You can fix this
> with compctl completion as follows:
> 
> 	compctl -D -f + -g .. -S / -q
Hm, I tried that before I saw Sven's patch, but it doesn't change anything.
Probably because I am using the new function-based completion.  Is compctl
useless in that case?  Or can the two methods be combined?

> That's because you're using expand-or-complete-prefix.
And you are right again!  Thank you so much for your help!
I turned it on because I wanted tcsh's behavior.

Thanks again for your fast answer,
 Andy.

-- 
 E-Mail: Andy@spiegl.de     URL: http://andy.spiegl.de
 PGP/GPG: see headers
                                o      _     _         _
  --------- __o       __o      /\_   _ \\o  (_)\__/o  (_)
  ------- _`\<,_    _`\<,_    _>(_) (_)/<_    \_| \   _|/' \/
  ------ (_)/ (_)  (_)/ (_)  (_)        (_)   (_)    (_)'  _\o_
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 If you have good memory you can forget the rest.

Re: two completion questions

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> If you're using the new function-based completion in 3.1.6, it's going to
> require some editing of the _path_files completer.  Hey, Sven, do you (or
> any other zsh-workers) remember the rationale for this handling of ".."?

In _path_files it's because globbing never produces . and ..

About compctl: I only vaguely remember lots of discussions about these 
two special cases.


Anyway, here's the patch for _path_files, for the latest version.

To tell you the truth: this also fixes two typos that made files not
starting with a dot not be used as possible completions if glob_dots
was unset and the string on the line started with a dot.

Bye
 Sven

diff -ru ../z.old/Completion/Core/_path_files Completion/Core/_path_files
--- ../z.old/Completion/Core/_path_files	Mon Dec 13 11:24:11 1999
+++ Completion/Core/_path_files	Mon Dec 13 11:27:49 1999
@@ -225,11 +225,11 @@
     if [[ "$tpre$tsuf" = */* ]]; then
       tmp2=( ${^tmp1}*(-/) )
       [[ ! -o globdots && "$PREFIX" = .* ]] &&
-          tmp2=( "$tmp1[@]" ${^tmp1}.*(-/) )
+          tmp2=( "$tmp2[@]" ${^tmp1}.*(-/) . .. )
     else
       tmp2=( ${^tmp1}${^~pats} )
       [[ ! -o globdots && "$PREFIX" = .* ]] &&
-          tmp2=( "$tmp1[@]" ${^tmp1}.${^~pats} )
+          tmp2=( "$tmp2[@]" ${^tmp1}.${^~pats} . .. )
     fi
     tmp1=( "$tmp2[@]" )
 

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: two completion questions

[Sven Wischnowsky]

Andy Spiegl wrote:

> > 	compctl -D -f + -g .. -S / -q
> Hm, I tried that before I saw Sven's patch, but it doesn't change anything.
> Probably because I am using the new function-based completion.  Is compctl
> useless in that case?  Or can the two methods be combined?

They can, see the file `Base/_default'. BUT: you don't want to do
that. It's naughty. Only there for people who already have lots of
compctls and want to be able to use them when moving to the new
completion system.

At least, that's how it's intended to be used ;-)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de