zsh-workers
 help / color / mirror / code / Atom feed
From: dana <dana@dana.is>
To: Oliver Kiddle <okiddle@yahoo.co.uk>
Cc: zsh-workers@zsh.org
Subject: Re: [PATCH] Completion batch #2: Misc. trivial fixes
Date: Wed, 3 Jan 2018 18:03:30 -0600	[thread overview]
Message-ID: <1C17F1B9-C935-44B0-A8E4-52D87EE76DE6@dana.is> (raw)
In-Reply-To: <18174.1515022825@thecus.kiddle.eu>

On 3 Jan 2018, at 17:40, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>Digging around in $_cmd_variant is essentially looking into the
>internals of _pick_variant. The documented interface is to use the -r
>option to _pick_variant. Also, it is not saving the full output of
>expand --version, it will either have the value "gnu" or "unix".

Well, maybe it's worth bringing this up now, then, before i submit any further
patches: The reason i'd added that check is that i wanted to be able to complete
commands like this:

  % busybox expand -<TAB>

This use case doesn't seem (necessarily) compatible with _pick_variant as-is,
because your unadorned `expand` may be a totally different variant from `busybox
expand`. The way i had handled this in the _busybox function is:

  _cmd_variant[${words[1]}]=busybox _normal

That way you can temporarily override what _pick_variant thinks the actual
variant is. This seems to work quite well, but i did feel some guilt about it,
since as you mention it's circumventing the interface.

Another issue i had with _pick_variant is dealing with risky commands. In most
cases i imagine it's probably fine to do something like `poweroff --help`... but
i certainly didn't want to take the chance, since a badly written poweroff might
just kill the machine if you're running as root. So i had again bypassed
_pick_variant and manipulated _cmd_variant myself.

Do you have a suggestion as to how i could accomplish things like this in a less
hacky way? Maybe _pick_variant could learn an option to set the variant
directly? Alternatively, maybe i am over-engineering everything again...?

On 3 Jan 2018, at 17:40, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
>Given that these are hidden options, excluding other numeric options is
>pointless. It is also arguably wrong because the tab width can be more
>than 9 characters wide: e.g. expand -20 is valid.

All i really wanted was to have it not offer -t if a numeric option's already
been given. The completion function doesn't have to know that -20 is different
from -2 -0 to do that, AFAIK. Didn't consider that excluding the other options
is pointless though, i suppose it is superfluous.

Thanks!

dana



  reply	other threads:[~2018-01-04  0:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-03 21:29 dana
2018-01-03 23:40 ` Oliver Kiddle
2018-01-04  0:03   ` dana [this message]
2018-01-04 11:47     ` Oliver Kiddle
2018-01-04 16:05       ` dana
2018-01-06  6:11         ` dana

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=1C17F1B9-C935-44B0-A8E4-52D87EE76DE6@dana.is \
    --to=dana@dana.is \
    --cc=okiddle@yahoo.co.uk \
    --cc=zsh-workers@zsh.org \
    /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).