zsh-workers
 help / color / mirror / code / Atom feed
From: Matthew Martin <phy1729@gmail.com>
To: zsh-workers@zsh.org
Subject: Re: [PATCH 4/4] _normal: Add -P to reset precommands
Date: Tue, 2 Apr 2019 21:01:41 -0500	[thread overview]
Message-ID: <20190403020123.GA98420@CptOrmolo.darkstar> (raw)
In-Reply-To: <dcc89fff-413a-441e-8f27-15ed4c0fabae@www.fastmail.com>

On Tue, Apr 02, 2019 at 04:27:41PM -0400, Daniel Shahaf wrote:
> dana wrote on Tue, 02 Apr 2019 17:47 +00:00:
> > On 1 Apr 2019, at 22:13, Matthew Martin <phy1729@gmail.com> wrote:
> > >+xitem(tt(_normal) [ tt(-P) | tt(-p) var(precommand) ])(
> > 
> > I know it wasn't your fault, but i think this should be item()(), not
> > xitem()(). I don't fully understand the distinction, but xitem() seems to be
> > used only when there are multiple headings (describing different ways to use
> > the command); left here, it breaks the man-page formatting for the paragraphs
> > you added.
> 
> There should be zero or more xitem() [with one pair of parens each]
> followed by exactly one item()() [with two pairs of parens, the second
> one being multiline).

Thanks for the explanation.

> Since I'm replying: I don't understand why `tt(foo) tt(bar) tt(baz)` is
> spelled with three macros; I think`tt(foo bar baz)` would be fine… but
> of course this is minor.

Because _multi_parts just above does something similar (although it's
alone in this file using that style). Fixed.

> > > completes after pre-command specifiers such as tt(nohup), removes the
> > 
> > Also not your fault, but this is the only place in the documentation
> > (including your changes) where 'pre-command' is hyphenated. Maybe fix that?

Fixed.

> > >+Append var(precommand) to the list of precommands. Should be used in
> > >+Reset the list of precommands. Should be used if completing a command
> > 
> > This clipped style (ommitting the subject of the sentence) isn't used anywhere
> > else in the documentation that i can see.

It's used with the other helper functions that describe their options in
a list (cf. _completers, _dir_sep, _email_addresses, although only -f
for _path_files). I think the imperative generally results in more
concise documentation for flags ("specifies that" doesn't add anything);
but if the declarative is preferred, I can change the patch to match.

> > >+  '*::arguments: _normal -p $service'
> > 
> > The 'arguments' here is superfluous.

Fixed.

> > idk if you planned to do another pass, but i noticed several straight-forward
> > examples of other functions that could make use of `_normal -p`: _env,

I'm planning to review uses of _normal next. This round was just
cleaning up completers that already used precommands.

      reply	other threads:[~2019-04-03  2:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02  3:13 Matthew Martin
2019-04-02 17:45 ` dana
2019-04-02 20:27   ` Daniel Shahaf
2019-04-03  2:01     ` Matthew Martin [this message]

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=20190403020123.GA98420@CptOrmolo.darkstar \
    --to=phy1729@gmail.com \
    --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).