git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jakub Narębski" <jnareb@gmail.com>
To: "SZEDER Gábor" <szeder@ira.uka.de>, "Duy Nguyen" <pclouds@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>,
	Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH/RFC] git.c: support "!!" aliases that do not move cwd
Date: Tue, 11 Oct 2016 15:24:47 +0200	[thread overview]
Message-ID: <d2de6d3f-5291-c68b-5db1-b55b81ca5c10@gmail.com> (raw)
In-Reply-To: <20161011135107.Horde.XsPGOYSpK0L1qW2xMcGqD1i@webmail.informatik.kit.edu>

W dniu 11.10.2016 o 13:51, SZEDER Gábor pisze:
> Quoting Duy Nguyen <pclouds@gmail.com>:
>> On Fri, Oct 7, 2016 at 10:55 PM, Jakub Narębski <jnareb@gmail.com> wrote:
>>> W dniu 07.10.2016 o 16:19, Johannes Schindelin pisze:
>>>> On Fri, 7 Oct 2016, Jakub Narębski wrote:
>>>
>>>>> Note that we would have to teach git completion about new syntax;
>>>>> or new configuration variable if we go that route.
>>>>
>>>> Why would we? Git's completion does not expand aliases, it only completes
>>>> the aliases' names, not their values.
>>>
>>> Because Git completion finds out which _options_ and _arguments_
>>> to complete for an alias based on its expansion.
>>>
>>> Yes, this is nice bit of trickery...
>>
>> It's c63437c (bash: improve aliased command recognition - 2010-02-23)
>> isn't it? This may favor j6t's approach [1] because retrieving alias
>> attributes is much easier.
>>
>> [1] https://public-inbox.org/git/20161006190720.4ecf3ptl6msztoya@sigill.intra.peff.net/T/#mb1d7b8f31d595b05105b8ea2137756761e13dbf4
>> -- 
>> Duy
> 
> The completion script is concerned in three ways:
> 
>   1. it has to get the names of all aliases, to offer them along with
>      git commands for 'git <TAB>' or 'git help <TAB>',
> 
>   2. it has to get the command executed in place of the alias, and
> 
>   3. strip everything that can't be a git command, so it can offer the
>      right options for the aliased command.

There is also a possibility to tell the completion script which git
command to use for option completion via some trickery, even if the
first git command of many used in script is not right (e.g. when
"$@" is passed somewhere in the middle).

I don't remember exact details, but let's look at source:

  # If you use complex aliases of form '!f() { ... }; f', you can use the null
  # command ':' as the first command in the function body to declare the desired
  # completion style.  For example '!f() { : git commit ; ... }; f' will
  # tell the completion to use commit completion.  This also works with aliases
  # of form "!sh -c '...'".  For example, "!sh -c ': git commit ; ... '".

Very nice.

> 
> The '!!' syntax is the easiest, I think it will just work even with
> the current completion code, no changes necessary.
> 
> The '(nocd)' form is still easy, we only have to add this '(nocd)' to
> that list of stripped words for (3), but no further changes necessary
> for (1) and (2).

Shouldn't the '!' vs '!!' / '(nocd)!' affect pathname completion?
Or do tab completion in subdir offer wrong completion of filenames
for aliases?

Best,
-- 
Jakub Narębski


  reply	other threads:[~2016-10-11 13:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06 11:41 [PATCH/RFC] git.c: support "!!" aliases that do not move cwd Nguyễn Thái Ngọc Duy
2016-10-06 18:42 ` Junio C Hamano
2016-10-07 11:20   ` Johannes Schindelin
2016-10-07 12:27     ` Duy Nguyen
2016-10-07 12:47       ` Matthieu Moy
2016-10-07 13:07         ` Duy Nguyen
2016-10-07 14:12         ` Johannes Schindelin
2016-10-07 14:31           ` Matthieu Moy
2016-10-07 14:11       ` Johannes Schindelin
2016-10-07 14:20         ` Jeff King
2016-10-07 17:42       ` Johannes Sixt
2016-10-07 17:50         ` Jeff King
2016-10-08  8:36           ` Johannes Schindelin
2016-10-09  6:01             ` Jeff King
2016-10-09  6:08               ` Jeff King
2016-10-09 11:32               ` Duy Nguyen
2016-10-09 20:58                 ` Jeff King
2016-10-10 17:52                   ` Junio C Hamano
2016-10-10 18:21                     ` Jeff King
2016-10-10 19:07                       ` Junio C Hamano
2016-10-11  9:44                   ` Johannes Schindelin
2016-10-11 10:53                     ` Duy Nguyen
2016-10-11 11:28                       ` Johannes Schindelin
2016-10-11 15:01                     ` Jeff King
2016-10-26 13:23                       ` Duy Nguyen
2016-10-26 16:08                         ` Junio C Hamano
2016-10-07 13:31     ` Jakub Narębski
2016-10-07 14:19       ` Johannes Schindelin
2016-10-07 15:55         ` Jakub Narębski
2016-10-08  0:32           ` Duy Nguyen
2016-10-11 11:51             ` SZEDER Gábor
2016-10-11 13:24               ` Jakub Narębski [this message]
2016-10-06 19:00 ` Jeff King
2016-10-06 19:07   ` Jeff King

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=d2de6d3f-5291-c68b-5db1-b55b81ca5c10@gmail.com \
    --to=jnareb@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=pclouds@gmail.com \
    --cc=szeder@ira.uka.de \
    /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 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).