From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17638 invoked from network); 29 Mar 1999 14:12:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Mar 1999 14:12:48 -0000 Received: (qmail 21632 invoked by alias); 29 Mar 1999 14:12:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5973 Received: (qmail 21625 invoked from network); 29 Mar 1999 14:12:34 -0000 From: "Andrej Borsenkow" To: "ZSH workers mailing list" Subject: Random comments about matchers Date: Mon, 29 Mar 1999 18:11:54 +0400 Message-ID: <002201be79ee$191ad9c0$21c9ca95@mowp.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 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 :-) 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 ... 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? 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 ... 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 ... 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). 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 :-) 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' ...). - and define some (compstate?) parameter with meaning "current matcher(s) to use" It would allow - easy cutomisation. User writes it's own function and simply sets matchers[_my_func] to whatever matchers (s)he likes - more (IMHO) robust. In this way we could move all code that tests for/sets matchers in several basic functions - (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. Well, I don't know, to which extent is it doable - but, as said, the current state probably needs some more think about ... cheers /andrej 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 ... P.P.S. Sven, thank you once more. Probably, I'd put this in my signature :-)