zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh-workers@zsh.org
Subject: Re: [PATCH v2] Correct completion of 'tmux new <TAB>'.
Date: Sun, 23 Jul 2017 09:48:05 +0200	[thread overview]
Message-ID: <19454.1500796085@thecus.kiddle.eu> (raw)
In-Reply-To: <1500659163.916799.1048510048.293AC92C@webmail.messagingengine.com>

Daniel Shahaf wrote:
> > I believe I understand what this is doing, but "if there is a single
> > argument" isn't entirely clear.  It does NOT mean "if there is a
> > single positional parameter in the call to this function" (which is
> > how I first read it, before I actually looked at the function
> > definition); rather it means "if there is more than one word in
> > argument position on the command line".
> > 
>
> I'll change to your wording before committing.  Thanks for the
> blind review!

For the documentation wouldn't it perhaps be better to describe the
basic use first. i.e. it is for commands that are ambivalent about
taking either a quoted command-string or a command and series of
arguments.

Your implementation will favour the _cmdstring variant in the sense that
completing a command-name will give you a quoted space as the suffix.
I think it would be preferable to check if the first and only argument
contains any spaces before switching to the _cmdstring variant and so
avoid unnecessary quoting.

We might also want to consider the many cases where we use the following
_arguments idiom:

  '(-):command:_command_names -e' \
  '*::args:_normal'

This also appears in if .. then .. else form in _strace and _socket.
It might be good to cover this with a single helper - _cmdrest perhaps
- but note that _precommand is not for this purpose: it completes
functions and aliases. I'm not convinced that _precommand should be
documented in this section at all. It wasn't really meant as a helper
but as a as a catch-all handler for the zsh precommand modifiers. Note
that it is in Zsh/Command.

I see a precommands array was added around 2009 in _precommand to
facilitate _calendar's check to see if it was run with command. What
do we want to include in this. It might be useful to collect all the
wrapper commands and not just zsh precommand modifiers. It is somewhat
similar to the _comp_priv_prefix that we added more recently.

Oliver


  reply	other threads:[~2017-07-23  7:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20 21:06 Daniel Shahaf
2017-07-21  3:12 ` Bart Schaefer
2017-07-21 17:46   ` Daniel Shahaf
2017-07-23  7:48     ` Oliver Kiddle [this message]
2017-07-23 14:01       ` Daniel Shahaf
2017-07-25  5:57         ` Oliver Kiddle
2017-07-25 12:01           ` Daniel Shahaf

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=19454.1500796085@thecus.kiddle.eu \
    --to=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).