zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: zsh workers <zsh-workers@zsh.org>
Subject: Re: using the description from _arguments foo:description:->state
Date: Wed, 21 Sep 2011 19:10:28 +0200	[thread overview]
Message-ID: <20002.1316625028@thecus.kiddle.eu> (raw)
In-Reply-To: <110921085012.ZM16562@torch.brasslantern.com>

Bart wrote:
> On Sep 21,  1:39pm, Oliver Kiddle wrote:
> } While we could, there's always the possibility that some function
> } somewhere has a -d that's intended to me an argument to be completed.
> 
> That condition is already handled by using e.g. "_arguments -n : -n".

True but that doesn't help for backward compatibility with old
completion functions.

> Before producing my patch I first thought about digging around in $expl,
> but $expl is already marked up for use with _format, so that doesn't
> really work.  Also $expl is only passed *down* from _arguments, not back
> up to the caller.

Well states are just a lazy way of avoiding separate functions. It'd be
nicer to get $expl across to them despite it not strictly being down
the call stack. However, I'll admit that having the description alone
is better than nothing.

> Yes, that's what my patch does.  $state_descr is an array parallel to

Sorry, it looks like I should have checked and read the beginning of the
thread before weighing in.

> Yes, that would work in _zle, but other callers of _arguments are already
> passing a description which _arguments parses out, only to then throw it
> away.  Shouldn't we keep that parsing in one place and make it useful?

Yes, fair enough. In many cases, the descriptions have been left blank
where they get thrown out in this manner but it would be nicer to have
them cleanly in one place.

So given that you "don't think adding -d buys much" and there is the
compatibility issue I mentioned, what would you suggest?  A local in
_main_complete would fall down in the case of a function using states
calling another function that also uses states but which doesn't declare
state_descr local. _arguments isn't used much from helpers but _values
is. Perhaps _arguments/_values could leave state_descr alone where
the description is blank or consists of just a space. That way the
documentation could also indicate that functions need only declare
state_descr local if they give a description for their states. The
implementation would have to take care in the case where $state has more
than one element, however.

Oliver


  reply	other threads:[~2011-09-21 17:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-11 15:04 Mikael Magnusson
2011-09-11 18:10 ` Bart Schaefer
2011-09-20 15:16   ` Mikael Magnusson
2011-09-21 11:39     ` Oliver Kiddle
2011-09-21 15:50       ` Bart Schaefer
2011-09-21 17:10         ` Oliver Kiddle [this message]
2011-09-22  4:04           ` 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=20002.1316625028@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).