From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24779 invoked from network); 14 Feb 1999 00:31:44 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Feb 1999 00:31:44 -0000 Received: (qmail 1628 invoked by alias); 14 Feb 1999 00:31:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5369 Received: (qmail 1620 invoked from network); 14 Feb 1999 00:31:24 -0000 From: "Bart Schaefer" Message-Id: <990213163057.ZM24185@candle.brasslantern.com> Date: Sat, 13 Feb 1999 16:30:57 -0800 In-Reply-To: <199902120842.JAA08278@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH: compadd (+ questions)" (Feb 12, 9:42am) References: <199902120842.JAA08278@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@sunsite.auc.dk Subject: Thinking about Functions/Completion/* differently MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 12, 9:42am, Sven Wischnowsky wrote: } Subject: Re: PATCH: compadd (+ questions) } } The problem is that the current approach is completion-centered, not } command-centered. Just think about someone who wants to use one of the } example completions for another command. I think we need to be neither command-centered nor completion-centered. We need a relational rather than operational view. We have all these files, many of which amount to nothing more than a map from a name like __aliases to an old compctl option letter. We need to recognize that this mapping is even more important than what the files contain. } I haven't thought that much about all this yet, but it would go like } this: } } We have a collection of context-names (completely shell-code based, } this is only vaguely connected to the CONTEXT parameter). For each } such context we have a definition saying what should be completed in } this context (such a definition could again be a function or an array, } re-using some of the code). This sounds OK so far ... } There would be a dispatcher-function that } gets the context-name as its argument and then invokes the } corresponding handler. What's the reason to do this with a dispatcher-function that takes an argument, rather than simply using a "case ... esac"? } We would then come up with files containing context-definitions (some } of the files are exactly that already and have names that show it, I } think that the fact that for other files names of commands seemed more } natural may be a hint that something went wrong). Not entirely. By contexts, here, you mean things like "now we are completing path names," "here we complete user names," "here we want alias names," "now file names ending in .gz," etc. Right? There are only a few such contexts that are general enough to apply to a wide range of commands. Most of those are already represented by old compctl options that take no arguments, and therefore can be directly implemented by calling complist. I don't think it's very useful to have separate files for defining each of these cases. Then there are a few other cases, like __x_options and __dvi, that are specific to a particular class of commands; and lastly there are the commands like __dd that have so many unique options that they form a context of their own. So if the goal was to have one file per context, you aren't far off. The hint that something is wrong is not the file names; it's the fact that some only do match generation, whereas others do what might be called "second-level dispatch." Match generation is actually NOT the hard part! The hard part is determining, from the command line, which context is the one in which you're completing. } Then we would need a way to connect command-names to context-names, } preferably in some automagically collected way. Connecting command-names to context-names isn't enough. A single command may have multiple contexts. So it seems that what we need (with the usual caveats about contexts like parameter substitution that need some other key than "command name") are: 1. For each command, something that maps the command line and cursor postion to one of a set of a contexts. (Some commands will never have more than one context.) 2. For each context that can be generated by (1), something that maps the command name to the set of possible matches for that context. (Some contexts will never care about the command name or other key.) 3. For each set of matches that can be generated by (2), something that maps the command and context to the code to insert the matches into the command line. (There's lots of builtin support for this already.) Some of those mappings may actually be multi-level, e.g., to implement completion after the -exec for "find ... -exec ...". Does this make sense? -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com