From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17969 invoked from network); 29 Mar 1999 14:57:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Mar 1999 14:57:42 -0000 Received: (qmail 26234 invoked by alias); 29 Mar 1999 14:57:21 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5974 Received: (qmail 26226 invoked from network); 29 Mar 1999 14:57:20 -0000 Date: Mon, 29 Mar 1999 16:57:13 +0200 (MET DST) Message-Id: <199903291457.QAA05825@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Mon, 29 Mar 1999 18:11:54 +0400 Subject: Re: Random comments about matchers Andrej Borsenkow wrote: > Looking at the examples more closely over the weekend (and trying to do > something useful myself :-) I'm still feeling uneasy about how matchers are > currently implemented ... > > 1. Currently users are expected to translate matcher desription into glob > pattern(s). I'm afraid, it is sometimes not trivial for normal users (I > don't claim, that matcher specs are trivial either :-) (You mean `_match_pattern' here, I think.) We could document it more verbosely, and it's much easier to do this for a given matcher than writing something general (and *much* faster). > 2. It is possible to use matchers only with completion function(s) that do > matching. In other words, we need one matcher definition for "normal" > completion and one glob pattern for "matching" one. > > 3. When testing for global matcher, we basically rely on order of > definitions to select needed one(s). Inserting a matcher in global array > will potentially cause havoc ... There is `compstate[matcher_string]', giving the *string* of the currently used global matcher. > 4. And, 'course, the problems in _path_files again and again ... Yes, I > know, the known :-) problems seem to be gone now ... but, really, user can > after all five _any_ pattern on command line. Or? But with a `_match_pattern' comparable to the global matcher this should still work. > 5. Sometimes we need matching in more tan one place (yes, this is a variant > of 2). Consider _long_options - we test given string against options array > and in another place we simply add it using compadd with matcher. Looks > naturally to use the same mechanism in both cases ... Yes, but see below. > 6. I have the feeling, that we test for matchers in wrong place! That is, > consider _path_files, _long_options etc. This functions are purely *helper* > functions - they actually have no idea (well, it is not entirely true in > case of _long_options ...) of what really is completed. The correct place to > set matchers is in functions that actually call these heplers ... For some of the things matchers are used for I really don't think that using them in completion functions is the right place, but instead the global matchers are the right thing to use (case-insensitivity, shortcut-keys, even some of the partial-word-thingies). > 7. The code relies on exisiting of _match_test and _match_pattern ... not > that I much like it (it makes the code at least less robust). Robust? Depends on your `_match_*' functions, I'd say ;-) > So, I have here a suggestion for 2 and 5 (and probably 4), rather vague idea > for 1, 3 and 6. > > 2,4,5 How hard (and useful) is to add matchers to a globbing flags? > Something, like > (#m(matcher spec))? The code seems to be there all right ... 'course, we > probably want low/upper versions to be the same (that is, just match but not > replace). In this way it will be possible to have a _single_ matcher spec, > that can be used with both globbing and non-globbing completion (and, > probably, useful outside completion as well). Consider bindkey example - > this would allow users to set matcher, that will be equally usable in all > cases (and then I agree, that explicit matches in functions are evil :-) I don't know how useful it would be, but it would be amazingly hard. I think I said this already, but anyway: when I first collected ideas for this matching stuff I thought a lot about using the globbing code for it, but then found too many problems. The matcher code in tricky.c has to deal with two strings and two patterns at the same time -- very different from the globbing code. The code has to build a matching string (different, since globbing only has to test existing strings) and it also has to collect a different kind of information: the cline structs I've already been talking about. They are needed to be able to build the unambiguous string. Given all that I have to admit that I didn't thinnk about making the globbing code call the completion code (and at that time we didn't have the `(#...)' globbing flags), only the other way round. Still, there is a problem: the globbing code is in the main zsh code, while completion is in a module and of course we don't want to put the completion code back into the basic shell. Of course, if we find uses where what you suggested might be useful anyway, we could think about moving part of the completion matching stuff there, but currently I see nothing where this might be interesting to have. Anyway, I'll have to think about this some more (and would like to hear about cases where such a pattern-matching enhancement might be useful). > 1,3,6 A somewhat vague idea is > > - use global matchers hash where keys are function names )_bindkey, > _configure etc) and values are matcher specs. We can add global matchers > with special keys (the simplest is `1', `2' ...). I think you mean shell code here... that's already possible. Implementation is left as an exercise to the reader. > - and define some (compstate?) parameter with meaning "current matcher(s) > to use" See above: `compstate[matcher_string]'. > It would allow > > - easy cutomisation. User writes it's own function and simply sets > matchers[_my_func] to whatever matchers (s)he likes If a user writes his own function he can easily add the `-M...' directly. > - more (IMHO) robust. In this way we could move all code that tests > for/sets matchers in several basic functions I don't think I understand this one -- there is currently only one function that has to be altered by the user. > - (combining with tee first part) setting matchers[] would provide for > unanimous habdling in both builtin and function code *irrespectively* of > wether we use globbing or simple completion. Ah, maybe you didn't mean shell code... but the completion (C-) code doesn't know from which function it's called (and it shouldn't know). > Well, I don't know, to which extent is it doable - but, as said, the current > state probably needs some more think about ... > > ... > > P.S. I forgot about 1. Well, So far the matchers are most commonly used for: > > 1. ignore the specified string > 2. case insensitive matching > 3. mutlipart matching (with separator) > > May be, if there were some simple way to tell exactly that (without all > hassle with patterns etc) it would be much more useful for end-users ... I once suggested (with code) a much simpler matching-stuff implementation allowing (roughly) what you said, but that didn't get included. Also, when suggesting the current implementation, I asked for help on the syntax -- and got only a sarcastic reply from Bart (Hi Bart, sorry Bart ;-). Adding syntactic sugar for the simple cases would be easy, just go ahead and make suggestions (and there even *is* already syntactic sugar -- the colon). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de