All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Felipe Contreras <felipe.contreras@gmail.com>
Subject: Re: [PATCH 2/4] completion: introduce __gitcomp_2 ()
Date: Fri, 03 Jan 2014 09:49:55 -0800	[thread overview]
Message-ID: <xmqqwqihlzuj.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CALkWK0mgqJFz1Lf_UVX8fdvnT+u+rp705dak7kXVFFBSr2bTQA@mail.gmail.com> (Ramkumar Ramachandra's message of "Fri, 3 Jan 2014 13:21:17 +0530")

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Junio C Hamano wrote:
>>         __gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "."
>>         __gitcomp_nl_append $"autosetupmerge\nautosetuprebase\n" "$pfx" "$cur_" " "
>
> This is not a bad idea at all. I'm just afraid that we might be
> leaving open ends: What happens if the $pfx isn't the same in both
> cases? Who keeps track of the index "i" of COMPREPLY (it's currently a
> local variable)? If we make it global, doesn't every function that
> deals with COMPREPLY be careful to reset it?

I am not sure what you are worried about $pfx; what does it do when
you have strings with different prefix in COMPREPLY? If it breaks,
then the answer is "don't do it then".

Doesn't an array know its own length and give you a way to ask?

> More importantly, can you see a usecase for more than two completion classes?

I am not sure why you think it is more important.

Somebody lacked forsight and designed an interface that would allow
only one "completion classes" (whatever that means) and called the
result sufficient. It has been sufficient for a long time.

Later you came, found that one was not enough, and added an inteface
that would allow only two, and called the result sufficient.  See a
pattern?

Anticipating unforseen possibilities for enhancement and preparing
an easy way to support them without overengineering is what the
"prepare an appending variant" suggestion is about, and by
definition, unforseen possibilities have not been seen yet ;-)

Imagine if one is flipping 47 topic branches from 6 contributors
whose names all begin with 'j'.  I can see that such a person would
appreciate if "git config branch.j<TAB>" did not dump all 47 topics
at once but offered "jc/ jk/ jl/ jm/ jn/ js/" instead, and then a
follow-up completion of "git config branch.jk/<TAB>" expanded to
names of topics from that single contributor "jk".  Wouldn't the way
to give these be either to return these two-letter hierarchy names
with slash as the suffix or to return list of two-letter plus a
slash with an empty suffix?  Either way, that is using something
different from a dot or a space, so that may count as the third, I
guess.

  reply	other threads:[~2014-01-03 17:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-30 14:52 [PATCH 0/4] Fix branch.autosetup(merge|rebase) completion Ramkumar Ramachandra
2013-12-30 14:52 ` [PATCH 1/4] completion: prioritize ./git-completion.bash Ramkumar Ramachandra
2013-12-30 14:52 ` [PATCH 2/4] completion: introduce __gitcomp_2 () Ramkumar Ramachandra
2014-01-02 23:47   ` Junio C Hamano
2014-01-03  7:51     ` Ramkumar Ramachandra
2014-01-03 17:49       ` Junio C Hamano [this message]
2014-01-03 19:09         ` Ramkumar Ramachandra
2013-12-30 14:52 ` [PATCH 3/4] completion: fix branch.autosetup(merge|rebase) Ramkumar Ramachandra
2014-01-02 23:56   ` Junio C Hamano
2014-01-03  7:36     ` Ramkumar Ramachandra
2014-01-03 17:32       ` Junio C Hamano
2014-01-03 18:58         ` Ramkumar Ramachandra
2014-01-03 19:13           ` Junio C Hamano
2013-12-30 14:52 ` [PATCH 4/4] completion: fix remote.pushdefault Ramkumar Ramachandra

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=xmqqwqihlzuj.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=artagnon@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.