From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13644 invoked from network); 11 Nov 1999 12:25:42 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Nov 1999 12:25:42 -0000 Received: (qmail 7178 invoked by alias); 11 Nov 1999 12:25:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8627 Received: (qmail 7170 invoked from network); 11 Nov 1999 12:25:26 -0000 From: "Bart Schaefer" Message-Id: <991111122358.ZM20320@candle.brasslantern.com> Date: Thu, 11 Nov 1999 12:23:58 +0000 In-Reply-To: <199911111024.LAA28735@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "New configuration -- should we..." (Nov 11, 11:24am) References: <199911111024.LAA28735@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Sven Wischnowsky , zsh-workers@sunsite.auc.dk Subject: Re: New configuration -- should we... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 11, 11:24am, Sven Wischnowsky wrote: } Subject: New configuration -- should we... } } [Maybe you'll all think that I have now gone completely mad...] Was that a pun? } Bart once said that if you have a programming language, don't implement } a second one -- and somehow the new completion system came into } existence. Apparently I need to listen to myself more often. } The completion system finds out the context in which completion is } attempted. This is a process in multiple steps, the overall context is } found using the `#compdef' stuff. The function thus then probably } knows about other finer-grained contexts. In each of these contexts } one or more types of matches can be generated. This is the place where } `_tags' is used. Here's a viewpoint that just occurred to me, and that might be helpful: The shell itself knows syntactic contexts. These are represented by the special `-context-' tokens. The shell also knows that when the `-command-' context is "filled in" (needs no further completion), it then implies a particular semantic context (completing the arguments of the specific command). #compdef maps the contexts the shell knows about to the functions that generate matches for those contexts. Superficially, every such function is different, because the semantics of every `-context-' and every command differ from the others (if they didn't, you wouldn't need to handle them individually). However, the very nature of interactions with filesystems and environments means that there are lots of overlaps in those semantics. (Otherwise the old compctl system, and completion in other shells, wouldn't work at all.) The idea behind _tags is to give names to those overlapping regions, and to organize them when more than one applies in any given situation. Now: } Instead of using some internally held configuration state we could } simply make `_tags' call a user-supplied function which gets the tags } supported in the current context and then has to `sort' them. I like this approach because it separates the "naming" function of _tags from the "ordering" function. That is, the current syntax for a tag represents a data structure that simultaneously maps a name to an action and a name to a priority. This new suggestion allows the tag syntax to bear only one of those burdens -- mapping name to action -- and leaves it up to the user-supplied function to do the ordering. There's still the issue of parameterizing the action, which is what the "style" part of the tag syntax accomplishes. Your second suggested implementation makes this explicit, which I like (though prefixing them with hyphens to look like options may not be necessary). One further thought, at the risk of distraction: Aren't these tags just describing more contexts? That is, what we're really trying to do is split the whole system into stages: (1) determine context, (2) generate appropriate matches, (3) organize matches for display. The farther apart we can drive these, the better; maybe there's even some way to cause the tags to become context-keys for _normal, or the equivalent? The trick is to balance the way zsh wants to organize things -- as the three stages above, each separately parameterized -- with the way users want to understand/express it, which is [*] first by generic behavioral preference for each "overlapping region" and second in large chunks by outermost context (i.e. per command). [*] As I see it. } There are two ways how we could make that function be called. Either } we do it only on the first call to `_tags' or on every call. The } latter would probably be more general but the first one presumably } would be easier when writing such a config function. I would think this really boils down to a computation-vs-memory tradeoff. That is, do you want to compute the mapping once and store it forever, or recompute it every time to save the storage? The function itself should not need to be significantly different either way, should it? } For the way how the config function says which tags are to be used I } currently see two possibilities (well, more than two, but these are } the easiest I see). In both cases the config function is only called } when `_tags' is called with the tags for the current state as } arguments, not when it is called to get the next set of tags to try. Thus separating "determine context and organize display" from "generate matches." Can you see a way to separate the first two, as well? } 2) The second way is based on support from `computil' (in a first } implemention-to-play-with it could be entirely in shell code). I like this so much better that I've ignored your first suggestion. } There could also be support to easliy set the pure config-tags, } i.e. the pseudo tags we add as a replacement for the config keys we } have now. I haven't yet thought too much about that part. Config keys / pseudo tags are the user's expression of generic behavioral preference. Maybe the right way to think of them is as global defaults for the comptry arguments, which can then be overridden locally by each config function? (Your follow-up in 8626 makes me think you're thinking this way, too.) } Only so } much: with support by C-code it would almost certainly be easy } enough to allow really arbitrary types for them. E.g. we could make } them be reported as strings, arrays, and assocs. With that it would } even be possible to use the same mechanism to replace some (or } all?) of the parameters we use now. This is especially interesting } for things like the `COMMAND_hosts_ports_user' because for the } `COMMAND' part we could use the context-switching this } configuration stuff is all about anyway. I /think/ this would make } it easier for users. I think this is looking in the right direction, but I can't think deeply enough into it at this point to be sure. } Ok, the more I think about this, the more I like it. Yes. } Also, someone please tell me if this is too complicated for the average } user. Is something like `conf2' really easier to understand? See my "The trick is ..." paragraph above. } Or does anyone have suggestions for, e.g. builtins or helper functions } that would allow us to make the config funcs better readable or } understandable? I don't yet ... -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com