From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6421 invoked from network); 8 Oct 2000 19:35:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 Oct 2000 19:35:55 -0000 Received: (qmail 29157 invoked by alias); 8 Oct 2000 19:35:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12926 Received: (qmail 29149 invoked from network); 8 Oct 2000 19:35:44 -0000 From: "Bart Schaefer" Message-Id: <1001008193538.ZM26883@candle.brasslantern.com> Date: Sun, 8 Oct 2000 19:35:38 +0000 In-Reply-To: <200010060814.KAA14507@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH: _expand, _expand_word, and their doc" (Oct 6, 10:14am) References: <200010060814.KAA14507@beta.informatik.hu-berlin.de> <000301c02f91$c51ed730$21c9ca95@mow.siemens.ru> <200010061300.PAA14911@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: _expand, _expand_word, and their doc MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 6, 10:14am, Sven Wischnowsky wrote: } } Bart Schaefer wrote: } > } > What would you (or anyone else) think of removing } > } > insert-all-completions from _expand entirely (thus eliminating } > } > the -c option) and instead put compstate[insert]=all at the end } > } > of _expand_word (after _main_complete)? } } 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). Hm. I don't have any overwhelming disagreement with that; the issue is not so much that _expand_word should handle it, as that _expand should not -- Andrej is clearly correct that _match is what actually does the most-correct thing in terms of generating the possible completions, so the question is how to get them all (offered to be) inserted at once. } So, I would mainly vote for changing the way the completions are } generated, using the way we do it in _prefix and _ignore, only the } other way round. I.e. we look up the completer style in the new } context and use the global list if it isn't set there. From that list } we remove the `uninteresting' completers as Bart did in _e_w (_prefix } and _ignore should probably do the same). That way the whole thing } would be self-contained again. I really am not entirely happy with the trick I used in _e_w. What it really should do is simply allow the completions to be generated the usual way and then stuff them all as a single match into a new group that could be named in the tag-order style (e.g. the expansion wouldn't appear if that style wasn't named in tag-order). } Then we leave it either in _expand or put it into a separate } completer, depending on how strongly people feel that this is } different from what _expand does [...]. I'd say we should use a new completer which has to appear very late in the completer list, and which modifies the handling of the completions that are generated before it is called. As you suggest here: } [...] And I think it would be possible, probably by adding } a new option to compadd which makes it add a string with all matches } generated so far (and then remove the `all' special value for } compstate[insert]). The only issue with removing the "all" special value is that we still should be able to express the idea that all the completions should be immediately inserted. If I understand your suggested change to compadd correctly, we'd just end up with all the completions as an *additional* choice. } With that, it would almost make sense to add that feature to _complete } itself, making it look (feature-wise) more like _expand. I don't think adding it to _complete is good enough, in particular because one may want to add all the completions generated by _match, which is not usually called until after _complete. On Oct 6, 4:34pm, Andrej Borsenkow wrote: } } > > 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. That's a non-answer: _expand_word does NOT select between individual expansions or all expansions. It just inserts all of them. So I ask again, why does it matter where "all of them" came from? The difficulty of course is that only "completion widgets" can be used to generate completions, so you have to go through the completion system even if what you want in the end is expansion. } 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. I don't agree with this. Globbing, for example, is a context in which the fixed set of possible values are files on the file system. The glob pattern doesn't create the values, it just selects the interesting ones. So you've just argued that "filename generation" should not be considered expansion, either -- but generating filenames is something that "expand", in the expand-or-complete sense, has always done. } 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). This might be an argument for why the _expand completer should not exist but I don't find it relevant to the question of why _expand_word should not be used to generate completions. On Oct 6, 3:00pm, Sven Wischnowsky wrote: } } I already decided to play a bit to see how difficult to implement this } is (both in C and shell code). Then once again I'm probably a bit late with this reply, but ... -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net