zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: Leveraging the completion system to discover available options in a command
Date: Fri, 01 Mar 2013 07:07:18 -0800	[thread overview]
Message-ID: <130301070718.ZM10378@torch.brasslantern.com> (raw)
In-Reply-To: <CAMz0A7=EuXF2YwRJhJLGGmmHCuTKxkMPeoT8J7xypb_h2LciNg@mail.gmail.com>

On Mar 1,  3:23pm, Idan Kamara wrote:
}
} Is it possible to use the completion system to get a list of available
} options for a command zsh knows how to auto-complete?

It's for most practical purposes impossible to use the completion system
unless you have an active ZLE $BUFFER to contain the inputs.

Within that constraint, you can create a function wrapper around compadd
that always passes one of the -O or -A options (and probably also -U) to
the builtin compadd whenever one of those options is not already present
in $@, and then invoke the appropriate completion widget with the "zle"
builtin to cause an array that you control to be populated with matches.

However, I don't think that actually addresses your desire:
 
} Ideally, I'd like given the name of a program to get a list of pairs
} (option string, desc) for each available option.

As far as I know there is no way to extract the "display strings" that
are loaded into compadd along with the matches, which would include the
option descriptions.

There is one fairly egregious hack you could employ; copy the technique
from Test/comptest from the zsh sources, which goes something like this:

1. Create a second interactive zsh running on a pseudo-terminal by using
   the zsh/zpty module.

2. Configure the list coloring styles in that copy of zsh to emit strings
   that format the completion list output into something resembling an
   XML structure.

3. Send input through zpty that causes the interactive slave shell to
   perform the completion you want, in list mode.

4. Parse the bits you want from the XML-ish output read with zpty.

You can then erase the command line from the slave shell and keep that
shell around to be able to repeat at (3) without setting up a new pty.
You get to deal with all the possible ways that having a second shell
running commands in the background might go horribly wrong for the user
of the shell in the foreground.


      reply	other threads:[~2013-03-01 15:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-01 13:23 Idan Kamara
2013-03-01 15:07 ` Bart Schaefer [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=130301070718.ZM10378@torch.brasslantern.com \
    --to=schaefer@brasslantern.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).