Zsh Mailing List Archive
Messages sorted by:
Re: completion within word
- X-seq: zsh-users 8025
- From: "Matthias B." <msbREMOVE-THIS@xxxxxxxxxxxxxxx>
- Subject: Re: completion within word
- Date: Mon, 27 Sep 2004 16:00:24 +0200
- Cc: zsh-users@xxxxxxxxxx
- In-reply-to: <17298.1096276791@xxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20040921175108.5a5f7697@xxxxxxxxxxxxxxxxxxxxx> <20040922045511.GA22277@xxxxxxxxxxxxxxxxx> <20040925003747.241f4a2d@xxxxxxxxxxxxxxxxxxxxx> <17298.1096276791@xxxxxxxxxxxxxxxxxxxxx>
On Mon, 27 Sep 2004 11:19:51 +0200 Oliver Kiddle <okiddle@xxxxxxxxxxx>
> On 25 Sep, "Matthias B." wrote:
> > Okay, I've tried it for a while and I'm not happy with it. I have the
> > same problems with it as with the bash programmable completion
> > project. Little annoyances everywhere such as "svn import k<TAB>"
> > refusing to complete on files in the current directory and there's
> > also the complexity. I feel
> The patch below fixes that particular annoyance. If you let us know
> about any other little annoyances,
Well, here's another one:
refuses to complete /usr. Same for
cvs import /us<TAB>
How can you guys live with a system that completely breaks basic path
completion? Over 99% of the time I want to complete paths, but seemingly
the completion code was written just for the remaining 1%. Are my work
patterns so different from everybody else's?
>we can either fix them or let you
> know how to configure zsh to avoid them.
Thanks for the offer, but I just don't have the patience to play
beta-tester for the completion code, which would probably require dozens
of fixes just to make sure I don't trip over a problem every couple days.
Every instance of a non-working completion is a major annoyance for me.
I've seen it with bash_completion and I see it again with zsh's completion
that for me the benefits simply do not outweigh the annoyances.
> I've tended to believe that we
> have fewer half-hearted attempts at completion functions than
My problem with bash completion was not half-hearted completion attempts,
it was the fact that whenever a specific completion existed for a command,
basic path completion for it seemed to be broken. zsh's code seems to
suffer from the same problem.
And this seems to be not just an issue of a few bugs. It appears to be a
conscious and major design decision for both projects, a design decision
that is incompatible with my work habits.
As I see it, bash_completion and zsh's completion get it all backwards.
They offer pathname completion only as a fallback and do even that only
when the completion code believes that a pathname makes sense in the
appropriate position. I'd like a completion system that works the other
way around. Pathname completion should *always* work *unconditionally* and
everything else should be offered in addition to it, if the completion
code believes it makes sense in the appropriate position. Under *NO*
circumstances should the completion code refuse to complete a path, just
because it believes (always erroneously!) that I'm trying to do something
But even if the completion system worked the way I want it to, there would
still be the complexity argument. It just makes me feel uneasy if just
pressing <TAB> touches who-knows-what files and calls who-knows-what
> > So I'm going to live with basic builtin completion. Any chances of
> > getting the above completion to work with it? If not, I'd be grateful
> > for pointers into the zsh code so that I can see if I can fix it
> > myself.
> I'm not entirely sure how to fix that from the builtin completion using
> only compctl.
As I said, pointers into the zsh code (I mean the C source code) are fine
with me. When I press <TAB> and nothing happens in a situation where bash
offers me something useful, that's a bug in zsh that needs to be fixed in
> situation. I'd suggest you just try to use the $path array form of $PATH
> instead because it is easier to manipulate. Instead of the your line,
> you can do:
> path=( $path /bi<tab>
> or in zsh 4.2:
> path+=( /bi<tab>
I know, but this doesn't help me. I actually encountered this problem with
a different variable and only used PATH as an example. Besides, as you've
probably noticed already I'm not the kind of person who'll just retrain
himself to work around shortcomings of a program. If a program doesn't do
what I want, the program has to change. The user is always right! :-)
A man without light need not fear darkness.
Messages sorted by: