From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17941 invoked from network); 1 Dec 1996 18:58:32 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 1 Dec 1996 18:58:32 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id NAA07433; Sun, 1 Dec 1996 13:38:20 -0500 (EST) Resent-Date: Sun, 1 Dec 1996 13:38:20 -0500 (EST) From: Zefram Message-Id: <19536.199612011838@stone.dcs.warwick.ac.uk> Subject: Re: Autoloading of compctl from dbm database file. To: schaefer@brasslantern.com Date: Sun, 1 Dec 1996 18:38:27 +0000 (GMT) Cc: fclim@singnet.com.sg, zefram@dcs.warwick.ac.uk, zsh-workers@math.gatech.edu In-Reply-To: <961201094226.ZM20801243@srf-58.nbn.com> from "Bart Schaefer" at Dec 1, 96 09:41:24 am X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]8508.88 X-US-Congress: Moronic fuckers Content-Type: text Resent-Message-ID: <"sv6cT.0.0q1.Q2Teo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2512 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu >> That is, bcompctl does the same job as compctl, but using a byte- >> compiled form instead of the normal options. "bcompctl -L > file" >> could be used to save byte-compiled compctls in a form that can be >> sourced quickly later. > >I don't think that goes far enough. If you still have to parse and >tokenize a command line for every compctl, the binary format hasn't >won you very much. The tokenisation is quite quick, though, isn't it? The commands that are output by the -L options are all simple commands, with only the simplest forms of quoting. And this has the advantage that the bcompctl commands could be merged with other commands, or made conditional if necessary. I think that bypassing compctl's complex command line parsing is worthwhile. (I'll do some profiling to check this.) >Further, {b}compctl -L would have to get a lot smarter, and merge >together into one output item the whole class of commands that use the >same compctl. Yes. I'd like compctl to do this in any case. >Version-independent will be the tough part; we'd better be darn sure >we're storing compctls internally in the form we'll always want to store >them, before we start saving them off as binary. We could have a version number embedded in the binary, so that we can make incompatible changes and gracefully reject old forms. We would usually want to avoid such changes, but that code doesn't change a great deal anyway. I think efficiency is likely to be the main problem. >A text format has some of the same problems -- I for one would love to >see compctl move away from all these cryptic command-line switches and >instead become a more structured construct with keywords etc. Yes, this has been suggested several times. I have vague plans of how this would work. I can see it blurring the distinction between extended completions and normal completions somewhat. -zefram