Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [RFC] Case-insensitive path completion in _git
- X-seq: zsh-workers 47739
- From: m0viefreak <m0viefreak.cm@xxxxxxxxxxxxxx>
- To: dana <dana@xxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxx>
- Subject: Re: [RFC] Case-insensitive path completion in _git
- Date: Sun, 13 Dec 2020 14:55:55 +0100
- Archived-at: <https://zsh.org/workers/47739>
- Archived-at: <http://www.zsh.org/sympa/arcsearch_id/zsh-workers/2020-12/c7ece4f3-86e4-36d8-527a-e99f8a8f11d1%40googlemail.com>
- Authentication-results: zsh.org; iprev=pass (mail-wm1-f42.google.com) smtp.remote-ip=209.85.128.42; dkim=pass header.d=googlemail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=googlemail.com; arc=none
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=YMF6XFgOoRARYDj5ycnIVdACf8QBPfnf/nMFE7h2T0Q=; b=D5bgyz+U9lsCWDTy5eYYTLY70UCEY1EkMBdGSCR9n1SiuGL156nVac76gWIqOihTBK 3UNVmVcdC/tvSb2vmjTfXitiKk+w6mYT2TnDMF7DOoT/k3fHVwYhnHAovG3rA2vjsGey iZBJY8qREI9jSi1Tz7HAN1gZDr7FCQMdTDx2IrjItEKkZ0AjK8iF+rwIyIA3X4ezMck4 MFvcjSjmmKW9Tc/C5fKrPMNmooMHuJOdOzHuNq6atlEi/5kSZRdBnO8MWyCQEKLDq9bc Yto9QnSVAomOm4QMlhOZW6KzzUyIJLCSYSoTeGf1qHkw974tz0twvILjde43LTprCHFc +zWQ==
- In-reply-to: <B25A8850-A141-4B81-A3E6-017F280B0CC6@dana.is>
- List-archive: <http://www.zsh.org/sympa/arc/zsh-workers>
- List-help: <mailto:sympa@zsh.org?subject=help>
- List-id: <zsh-workers.zsh.org>
- List-owner: <mailto:zsh-workers-request@zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-subscribe: <mailto:sympa@zsh.org?subject=subscribe%20zsh-workers>
- List-unsubscribe: <mailto:sympa@zsh.org?subject=unsubscribe%20zsh-workers>
- References: <B25A8850-A141-4B81-A3E6-017F280B0CC6@dana.is>
- Sender: zsh-workers-request@xxxxxxx
On 13.12.2020 05:40, dana wrote:
_git has issues completing files case-insensitively (if you have matcher-list
'm:{a-zA-Z}={A-Za-z}' or whatever). Looking into it, i found that __git_files
is trying to pass a glob pattern to `git ls-files`, and this fails if there's
not an exact case match, since ls-files is always case-sensitive.
There is a fall-back to `git ls-files` with no path, but this doesn't always
work either, because it defaults to the CWD, and the file you're trying to
complete may not be under the CWD. Even when the fall-back succeeds, it's not
ideal, because it'll pass every single file in the tree to _multi_parts, which
can be slow.
The following hack solves the problem for me, but it might be too silly to
commit. Can anyone think of a more proper fix? If not, would the hack be
viable (probably gated behind a style)?
dana
...
+ pref=${pref//(#m)[[:alpha:]]/\[${(U)MATCH}${(L)MATCH}\]}
...
This solution only handles simple upper-lower-case conversion matcher-list styles,
but it will not work for more complicated styles like 'r:|[._-]=* r:|=*'.
That's probably fine for most use-cases.
I have been running with the following patch applied locally for quite some time:
diff --git a/Completion/Unix/Command/_git b/Completion/Unix/Command/_git
index 81a060e4d..1a6619e31 100644
--- a/Completion/Unix/Command/_git
+++ b/Completion/Unix/Command/_git
@@ -7153,7 +7153,7 @@ __git_files () {
# TODO: --directory should probably be added to $opts when --others is given.
local pref=${(Q)${~PREFIX}}
- [[ $pref[1] == '/' ]] || pref=$gittoplevel$gitprefix$pref
+ [[ $pref[1] == '/' ]] || pref=$gittoplevel$gitprefix
# First allow ls-files to pattern-match in case of remote repository
files=(${(0)"$(_call_program files git ls-files -z --exclude-standard ${(q)opts} -- ${(q)${pref:+$pref\*}:-.} 2>/dev/null)"})
It just lets _multi_parts do the matching.
Performance-wise, it's obviously worse than than your proposed solution, but
still better than the fallback, since it still passes $gitprefix to ls-files,
which should also avoid the CWD problem.
The trigger of the fallback is broken anyways, isn't it?
# If ls-files succeeded but returned nothing, try again with no pattern
if [[ -z "$files" && -n "$pref" ]]; then
It just considers the case where no match was found at all, but it does not
handle the case where *some* matches were found, but not all.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author