From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4934 invoked from network); 6 Oct 2000 12:34:49 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Oct 2000 12:34:49 -0000 Received: (qmail 14418 invoked by alias); 6 Oct 2000 12:34:37 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12916 Received: (qmail 14411 invoked from network); 6 Oct 2000 12:34:36 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: Subject: RE: PATCH: _expand, _expand_word, and their doc Date: Fri, 6 Oct 2000 16:34:29 +0400 Message-ID: <000301c02f91$c51ed730$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-To: <200010060814.KAA14507@beta.informatik.hu-berlin.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > > > > You're starting from an initial pattern and expanding it into a set of > > strings, aren't you? What difference does it make whether the way you > > got those strings was by globbing, parameter substitution, history, or > > by invoking the completion system, or anything else? > Pragmatical answer: because currently we can select between individual expansions or all expansions, but cannot do it with completions. Metaphysical answer: I always considered expansion to be complementary to completion. Completion is always context-sensitive (in the very broad sense sometimes). We select from the fixed set of possible values; this set depends on context but values itself do not depend on initial pattern. With expansion we just evaluate the pattern; thus, the set of values does not depend on context in any way, but values itself obviously depend on initial string. Exactly the fact that completion is context-dependent action makes it possible (in most cases) to group matches, to provide decriptions etc. All this is inherently impossible with expansions, that do not have any internal structure (the only sensible way to group them is by the way intial string is evaluated - globbing, parameter expansion - that is done currently). Mmm ... sorry, I have not expected it to be so long :-) > > Anyway. The reason why I don't really like the completions style to be > handled there is that -- as Andrej mentioned once -- the matches are > generated different than the expansions. Not even by _expand itself > (which just looked like a clever trick at that time). > Excellent terse form of the above :-)) > > I don't, however, like to put it only into a bindable command, because > then people can't configure it to get all completions with, say, a > numeric prefix and TAB. And just adding a bindable command that makes > all completions be inserted when we have a completer for it is simple > (or just documenting the trick with _generic). > Well, it is a matter of taste. I prefer to get a list first and then decide if I want to insert it. It takes exactly the same amount of keystrokes; does it make any difference between 'ESC-1-TAB' and 'TAB-^X-i'? Implementing this needs a bit more than just wrapper around completer but does not need any extra C-code at all (almost - issue with menu-selection remains). Question to Sven - with noautolist, noautomenu - which value compstate[old_list] has after the first TAB? Is list still generated and kept internally even if it is not shown? > So, does that thing with allowing completions added separately to be > offered together with a string with all completions sound too esoteric > or do you really like it. And should we then put it into _complete? (I > mean, the weekend is coming up, so I should have the time to try to > implement it... ;-) > I probably won't use it, but won't object, of course. -andrej