Re: PATCH: Re: ignored-patterns giving correction a go

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> ...
> 
> [_next_tags]
> } > ... what happens if you invoke it as
> } > a widget but it's NOT in your completer list?
> } 
> } The end of civilisation as we know it...
> 
> The point being that perhaps it should not be bound to a key by compinit
> if it's not in the completer list by default ...

Ah, right. The patch does that (I think this is saver than changing
the default completer value).

> [Trailing -number on completer context]
> } No, it's only used for matcher-list and prefer-ignored, as documented.
> } Just so that I don't forget it, the patch below takes back a part of
> } your doc change. *But*: should we change it so that your documentation 
> } becomes true?
> 
> It's too bad those things have to be wedged into the context string.
> It feels as though they should be somewhere else.
> 
> } I played with this idea, too... One problem: approximate 
> } (and correct) use the same syntax already to include the number of
> } errors currently accepted. So we would have `complete-1',
> } `correct-1-2' and so on
> 
> I don't think I like having two such suffixes on the same completer.

Yep, that's why I didn't do it.

> } > So what if we just made the alternate set a group of its own, on the
> } > same level as the -default- group, e.g. -alternate-.  Change the -a
> } > option of compadd to require an argument, `-a alternate-group-name'
> } 
> } Yes, I once thought about using a different group, too. Hadn't thought 
> } about allowing users to give it a name, though... Hm. What makes me
> } uneasy about it is that this would make it even more complicated.
> 
> I'm not especially worried about it being complicated for people who are
> deep enough into it to be writing functions that use alternate sets.  The
> people who have to configure it are the ones who should get off easy.

It's also that the alternate set stuff as it is now only gives you all 
or nothing. One can't say that one *never* wants to see some
matches. As soon as there are no other matches, the alternate set code 
will give you the excluded ones. If we implement ways to completely
handle such exclusions-or-not in shell code, users would be able to
say which matches they never want and which matches they may want --
and when.

> (Back when we first started discussing the new completion system, my idea
> was that lots of people would need to write their own completers, and I
> was worried about making the functions easy to understand.  Now we have a 
> huge library of highly configurable functions, so hardly anyone is going
> to need to write one ... it _should_ be easier to configure the ones we
> have than it is to write new ones ...)

Yes.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx