From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Questions/comments on completion code that arise from PWS's zsh guide
Date: Thu, 24 Feb 2000 09:51:44 +0100 (MET) [thread overview]
Message-ID: <200002240851.JAA15340@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Bart Schaefer"'s message of Wed, 23 Feb 2000 16:17:08 +0000
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@informatik.hu-berlin.de
next reply other threads:[~2000-02-24 8:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-02-24 8:51 Sven Wischnowsky [this message]
2000-02-24 17:45 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
2000-02-28 9:36 Sven Wischnowsky
2000-02-28 9:47 ` Andrej Borsenkow
2000-02-28 10:16 ` Tanaka Akira
2000-02-25 13:16 Sven Wischnowsky
2000-02-25 16:55 ` Bart Schaefer
2000-02-23 16:17 Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200002240851.JAA15340@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).