Re: completion within word

["Matthias B." <msbREMOVE-THIS@xxxxxxxxxxxxxxx>]

On Mon, 27 Sep 2004 11:19:51 +0200 Oliver Kiddle <okiddle@xxxxxxxxxxx>
wrote:

> 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:

man  /us<TAB>

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
> bash_completion.

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
stupid.


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
commands. 

> > 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
the source.

> 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! :-)

MSB 

-- 
A man without light need not fear darkness.