Re: Autoloading of compctl from dbm database file.

[Zefram <zefram@xxxxxxxxxxxxxxxxx>]

>> 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