Re: ideas: free-search-complete, noexpand

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer wrote:

> On Aug 5,  8:29am, Sven Wischnowsky wrote:
> } Subject: Re: ideas: free-search-complete, noexpand
> }
> } ... it seems that I received all messages from the list, so I guess
> } noone has found the time/was interested enough to look at my last
> } patch, right?
> 
> Haven't found the time.  However, I do wish you'd broken this up into
> smaller patches, i.e., put the -W change, the explanation string %
> sequences, the =foo completion change, and pattern compctls each into
> its own patch (it's OK if some patches depend on others).
> 

Yes, I almost expected this comment, but I didn't have much time. And
the patch is thought as a collection of possibilities. If I get
remarks such as `I like this, but not this' and Zefram finally says
which parts he would like to include into the baseline (if any), I
would provide patches for those only.
But it is important to notice that most of the patches rely on the new 
internal representation for matches (which is responsible for the
biggest part of the patch). The only exceptions are the % sequences in 
explanation strings and the =foo completion change. Anything else
(even the -W stuff) needs the possibility to produce inclusively or'ed 
lists of matches.
About pattern compctls: of course, we could have this without inclusively-
or'ing, but then completion searching would stop at the first pattern
compctl found which I consider unacceptable (and we would need special 
casing for -T again).

Well, with the internal changes as a basic patch I could have put the
other things in different patches, but that would have required
writing some functions for one patch, then deleting/replacing those
functions for another patch and so on. The intermediate step of
implementing function that are not needed/completely different in the
patch with all the stuff is what kept me from making it this way.

But I can well understand your dislike, sorry.

> Ast a general remark, I find myself frowning over a number of the option
> choices, particularly "-t+ +", but in most cases I eventually (sometimes
> many paragraphs of your message later) figure out why you did things, so
> I don't immediately have any alternatives to suggest.
> 

Again, I wholeheartedly agree. I would prefer to put things into
separation sequences: one like `+' but meaning inclusive-or, one like
`-' but meaning `continue to test patterns' and so on. This would make 
parsing more complicated and I just didn't find enough good sequences
that wouldn't introduce incompatibilities (in a first version I used
`-+' instead of `-t+ +', but making continuing after `+' different
from all others didn't look right, either).

So, hesitantly, I used only one option for all of them (but at least
that gave me the possibility to use characters that should be easy to
remember).

> While we're on the topic, I've always been somewhat bothered by the use
> of ';' in extended completion patterns like this:
> 
> 	compctl -x 'r[-e,;]' -l '' -- xterm
> 
> What's really meant there is not really "a word beginning with ';'" but
> rather "the end of this command" which may be signified by any of ; & |
> ;; && || or }.  I suspect this idiom arose from the "find" example in the
> man page, where it -does- mean "a word beginning with ';'", and it just
> happens to work for most cases.  However, there really is a need for a
> way to specify a range "... up to the next command separator" and there
> is presently no way to accomplish that; closest would be 'R[-e,[;&|}]]'
> which is ugly and unnecessarily applies pattern semantics to the "-e".
> Any suggestions?
> 

No. The `r[-e,;]' matches a quoted `;', not the command separator. In
fact there is no way to match the command separator, since the
completion code uses only the words of the current command.
Since you seem to think that the completion code sees more of the
line, this raises the question if it should. I can't think of an
example where this would be interesting to have (or even needed), can you?


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx