Re: Questions/comments on completion code that arise from PWS's zsh guide

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> These are mostly things I've been wondering about for a while, but
> reading their descriptions all in one place has set me off.
> 
> Completing files after `=' is enabled for `dd' even if `magicequalsubst'
> is not set -- but of course tilde-expansion doesn't happen when the
> command is finally executed unless `magicequalsubst' IS set.

Hm, right. One solution would be to add a new option to _path_files
saying that it shouldn't complete ~/... But a better solution might to 
just make _path_files check if $IPREFIX ends is not empty and if it
is, only complete after `~' if it ends with a `=' and magicequalsubst
is set. But then... it will always be the user's fault if there is a
tilde in such a place. Hrm, just make _path_files add a warning to the 
list?

> No one has ever explained adequately why accept-and-infer-next-history
> is overloaded in menu-selection, rather than accept-and-menu-complete.
> If it's to preserve accept-and-menu-complete's semantics of starting
> a new completion at the current level, then what about preserving the
> semantics of accept-and-infer-next-history? Why preempt an existing
> widget at all? Just to keep somebody from binding the new one in the
> wrong keymap? (The "history" in there bugs me, it has nothing to do
> with history.) At least choose one that no one would reasonably want to
> invoke in the middle of menu-selection, perhaps even "menu-complete"
> itself!

Hm. First: as the manual says (see? I *did* explain it -- almost),
accept-and-menu-complete and accept-and-hold make the selected match
be kept and selection be continued -- just what a-a-m-c normally does.
I once had this idea of adding dummy widgets in the complist module,
like menu-select-{up,down,...,accept} and so on. The problem is that I 
would also like to automatically allow users to continue using their
bindkeys if, for example, they happen to have reverse-menu-complete on 
some key.

> Why doesn't _multi_parts accept and pass through the -f option of
> compadd?

_multi_parts was added when we wrote the function for tar and there it 
simply won't work (I mean the list_types bit). But yes, we could
easily change that... see the patch below.

> Why does the users-hosts style want `user:host'? Is there a problem with
> the @ sign that I fail to see?

That part of the guide made me think about it, too. As far as I can
see, it shouldn't be too hard to change _combinations to allow this.


Bye
 Sven

diff -ru ../z.old/Completion/Core/_multi_parts Completion/Core/_multi_parts
--- ../z.old/Completion/Core/_multi_parts	Wed Feb 23 14:43:41 2000
+++ Completion/Core/_multi_parts	Thu Feb 24 09:49:35 2000
@@ -15,7 +15,7 @@
 
 zparseopts -D -a sopts \
     'J:=group' 'V:=group' 'X:=expl' 'P:=opts' 'F:=opts' \
-    S: r: R: q 1 2 n 'M+:=match' 'i=imm'
+    S: r: R: q 1 2 n f 'M+:=match' 'i=imm'
 
 sopts=( "$sopts[@]" "$opts[@]" )
 if (( $#match )); then
diff -ru ../z.old/Doc/Zsh/compsys.yo Doc/Zsh/compsys.yo
--- ../z.old/Doc/Zsh/compsys.yo	Wed Feb 23 14:43:23 2000
+++ Doc/Zsh/compsys.yo	Thu Feb 24 09:50:00 2000
@@ -2121,7 +2121,7 @@
 like completing pathnames, the tt(-i) option should not be used.
 
 Like other utility functions, this function accepts the `tt(-V)',
-`tt(-J)', `tt(-1)', `tt(-2)', `tt(-n)', `tt(-X)', `tt(-M)', `tt(-P)',
+`tt(-J)', `tt(-1)', `tt(-2)', `tt(-n)', `tt(-f)', `tt(-X)', `tt(-M)', `tt(-P)',
 `tt(-S)', `tt(-r)', `tt(-R)', and `tt(-q)' options and passes them to
 the tt(compadd) builtin.
 )

--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx