Re: When can we make a compromise in Git completion?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 6,  1:07am, Felipe Contreras wrote:
} Subject: When can we make a compromise in Git completion?
}
} Actually I saw that mail by looking at the archives, but I didn't
} notice the patch. I have tried the patch, it's still *dead slow* for
} me. Again, I don't think this can be solved without writing new git
} plumbing. You need to avoid 'git ls-files'.

With the patch, however, it's possible for you to plug in your own
different plumbing using zstyle.

zstyle ':completion::complete:git:*:files' command ...

where you put your alternate plumbing in where I have "...".

Then when you have something that works as fast/accurately as you care
about, you can let us know.

If that's not good enough you can rewrite __git_files (or any of the
other functions in the _git file) from scratch; there's a reason that
the source file tests (( $+functions[__git_files] )) || ... before
each function is defined:  so that you can override them simply by
defining your own flavor before _git is autoloaded.

} So. At which point are you going to be willing to accept the fact that
} it's not possible to fix the performance without making a compromise?

Roughly at the time you stop taking such an antagonistic stance about
it, I suspect.  Really, you're not doing your efforts any favors by
framing the discussion the way you do.

Whether Nikolai personally accepts your suggestions for inclusion in
his contributed code is actually something of a side issue.  The real
question is whether this is important enough to you to make it work for
yourself.