Re: [PATCH 4/4] completion: avoid user confusion in non-cone mode
- From
Elijah Newren <newren@gmail.com>
- Date
- Dec 3, 2023, 05:57 UTC
- Message-ID
- <CABPp-BHDx+e6dS9zNrS87-ROvr08p4YNqs5KUHF3E67DJRWihg@mail.gmail.com>
- In-Reply-To
- <xmqq34ws3rfa.fsf@gitster.g>
On Sun, Nov 26, 2023 at 5:39 PM Junio C Hamano <gitster@pobox.com> wrote: [...]
Show 31 quoted lines
> >> Hmph, would an obvious alternative to (1) check against the HEAD (or > >> the index) to see if the prefix string matches an entity at the > >> current directory level, and then (2) to prefix the result of the > >> previous step with "/$(git rev-parse --show-prefix)" work? That is > >> something like this: > >> > >> $ cd t > >> $ git sparse-checkout add help<TAB> > >> -> > >> $ git sparse-checkout add /t/helper/ > > > > I thought bash-completion was only for completions, not for startings > > as well. Was I mistaken? > > To my mind, the completion is what I as an end user get when I type > <TAB> to help me formulate input that is acceptable by the command. > As I said, I consider it a bug (or UI mistake) in the a command if > it pretends to work inside a subdirecctory but complains when it is > given a path relative to the current directory, so I'd rather prefer > the approach to "fix" the underlying command, but if that is too > much work or cannot be done for whatever reason, the second best > would be to turn whatever we can do to help the end-user input into > a form that is accepted by the command without changing what the > input means. If it takes more than "appending at the end", that is > fine, at least by me as an end user. > > If you are saying "completion code can only append at the end > because we can only return strings to be appended, not the entire > strings, to the readline machinery, so mucking with the start of the > string is not doable", then sorry---I accept that what we cannot do > cannot be done, and in that case you are "not mistaken".
This was what I thought; that bash completion didn't support this.
Show 6 quoted lines
> But from the existing use of COMPREPLY[], it didn't look that way > (it seems __gitcomp is equipped to take fixed prefix to all > candidates by passing it in $2 and used to complete names of > configuration variables in a section, but it seems to me that it can > be repurposed when prefixing "$(git rev-parse --show-prefix)" to a > given pathname relative to the $cwd).
Ooh, that's really interesting; I had no idea it had this kind of flexibility. It does feel like we're abusing "bash completions" to be both "bash completions AND startings", but I agree that this is a case where it makes sense to do so.
I changed patch 4 to implement this for non-cone mode, and submitted v3 with that change.