zsh-workers
 help / color / mirror / code / Atom feed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Eric Cook <llua@gmx.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [RFC/PATCH] completion: git: add fast mode
Date: Wed, 25 Nov 2020 18:22:19 -0600	[thread overview]
Message-ID: <CAMP44s2U9WO7PNzKPCTOf5inPaDu6MysTuwviDyNPZECLinKdw@mail.gmail.com> (raw)
In-Reply-To: <2fe66d4d-33c9-cde2-2833-e656c07b5a2f@gmx.com>

On Wed, Nov 25, 2020 at 4:56 PM Eric Cook <llua@gmx.com> wrote:
>
> On 11/25/20 5:34 PM, Felipe Contreras wrote:
> > I think the overall end goal would be to move as much as possible of
> > the completion to the Git project itself. For example; git commands
> > have the --git-completion-helper option, which throw something like:
> >
> >    % git version --git-completion-helper
> >    --build-options --no-build-options
> >
> > There is no _git_version() specific function in Git's bash completion,
> > and yet when you type "git version --<tab>" the options are completed
> > anyway.
> >
> > This helps so that new commands get some automatic completion, even
> > when nothing specific for them is done in the completion script.
> >
> > It has been discussed in the mailing list to add something similar for
> > zsh specific completion, so the descriptions are generated too, and
> > shorthand forms, perhaps with --git-completion-helper=zsh.
>
> This is a form of completion that may work for bash since it's completion system
> is simpler and user expectation is (seemingly) solely "press tab and stuff appears".
> where as zsh's completion systems allows the user to manipulating the results in
> various ways which could be lost once $program handles the completion.
>
> like adding additional results
> overriding opinionated file completion set by the author(s)
> omitting options you don't want presented to you.
> grouping results by tags.
> just to name a few.
>
> zsh's completion system is far more powerful than just presenting a pseudo static
> list of options with descriptions.

This is a false dichotomy.

You can do both things: 1. extract the options and descriptions from
the git program, and 2. use code to rearrange them, group them, and do
whatever else you want with them.

-- 
Felipe Contreras



      reply	other threads:[~2020-11-26  0:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 17:56 Felipe Contreras
2020-11-25  0:19 ` Daniel Shahaf
2020-11-25  3:54   ` Felipe Contreras
2020-11-25 14:48 ` Eric Cook
2020-11-25 22:34   ` Felipe Contreras
2020-11-25 22:56     ` Eric Cook
2020-11-26  0:22       ` Felipe Contreras [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=CAMP44s2U9WO7PNzKPCTOf5inPaDu6MysTuwviDyNPZECLinKdw@mail.gmail.com \
    --to=felipe.contreras@gmail.com \
    --cc=llua@gmx.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).