From: Oliver Kiddle <firstname.lastname@example.org>
To: Zsh hackers list <email@example.com>
Subject: Re: [PATCH] Make _expand_alias more usable as a completer
Date: Thu, 03 Jun 2021 01:23:55 +0200 [thread overview]
Message-ID: <36227-1622676235.815398@zrY_.ZerV.zhJL> (raw)
On 29 May, Marlon Richert wrote:
> When _expand_alias is invoked as a completer, if 'complete' is set to
> 'true', let _expand_alias always return 1. This is analogous to how
> this style behaves when _expand_alias is invoked as a widget or when
> the _expand completer's 'accept-exact' style is set to 'continue',
> which allows you to put it at the start of the 'completer' list.
In practical tests, I'm not finding that this works too well, it ends up
removing the characters typed. From _expand_aliases, you end up with a
call to compadd -QU and later you get a compadd -Q. For testing play
around with the following:
compadd -QU 'ls -al'
compadd -Q lsusb lsvfs
compdef _foo foo
I can see the motivation for the feature but it needs compstate[insert]=menu
to be usable, at least from my setup. Setting that tends to be applicable
wherever you're using -U to change what was typed so far.
It feels like a bug that this example can't recognise the unambiguous
"ls" prefix but aliases often expand to something quite different to the
initial alias name.
I also wonder if this would be better done from within _command_names
directly but I'm not sure.
next prev parent reply other threads:[~2021-06-02 23:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 21:59 Marlon Richert
2021-06-02 23:23 ` Oliver Kiddle [this message]
2021-06-03 21:42 ` Marlon Richert
2021-06-20 19:49 ` Lawrence Velázquez
2021-06-20 21:08 ` Mikael Magnusson
2021-06-20 22:24 ` Marlon Richert
2021-07-18 23:34 ` Lawrence Velázquez
2021-07-28 3:23 ` Bart Schaefer
2021-08-01 18:50 ` [PATCH] Make _expand handle aliases (was Re: [PATCH] Make _expand_alias more usable as a completer) Marlon Richert
2022-03-31 22:35 ` Lawrence Velázquez
2022-04-01 0:37 ` Bart Schaefer
2022-05-06 5:57 ` Marlon Richert
2022-05-07 20:39 ` Bart Schaefer
2022-05-11 7:32 ` Marlon Richert
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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
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).