Re: ideas: free-search-complete, noexpand

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 6, 10:03am, Sven Wischnowsky wrote:
} Subject: Re: ideas: free-search-complete, noexpand
}
} Bart Schaefer wrote:
} 
} > As 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
} 
} 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).

That's not quite what I meant.  For example, it's not clear that in

	compctl -k '(foo bar)' -t+ + -k foobar + -f

that the + immediately after the -t+ is an "or" but the next + is an
"xor".  That is, the "scope" of -t isn't obvious.  If I wrote

	compctl -t+ -k '(foo bar)' + -k foobar + -f

then it would (I think) mean the same thing, but now it -looks- as if
it means something different.  In this case, I think any mnemonic value
in using + to follow -t is outweighed by the (human) parsing confusion.

My problem with the -J/-V options is that they look just like all the
options that can be freely reordered, but they're order-dependent.  The
best thing about + (and the use of - within extended completion) is
that they don't resemble any of the simple flags etc.  I'd almost rather
have seen \( ... \) for sorted groups and \{ ... \} for unsorted, or
something like that.

(Which brings me back to the long-ago complaint that completion is really
too complex to be a command, and ought instead to be its own language or
function-body-like control structure.)

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

Er, yes, if I'd thought about it a bit longer, I did know that.  What I
was trying to get at was not the need to match the command separator, but
the need to have something that doesn't match -anything-, so as to force
the range to extend to the end of the argument list.  Using ';' works
only because it's very rare to pass a quoted ';' as an argument, but it
is really just a workaround for a missing concept and is meaningless to
anyone who doesn't know the idiom.

} 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?

Only if you wanted to make compctls for control structures, e.g. to be
able to complete the word "then" following the ; in an "if ... ;".
That isn't where I wanted to go, though.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com