Moving away from compctl

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

We had this bit of discussion about making the completion code
cleaner, making the interface cleaner, and so on.

Just to summarise, here is what I'd like to do in the near future. So
now is the time to speak up if you don't like any of these or have
suggestions for how to make something better (or suggestions for new
things which you think should be made possible). Also, I'll again be
asking many questions here...


My aim is to take the first steps to be able to remove old
code. Especially that code that is only used by `compctl' and
`compgen' now. For the time being `remove' means: to put into a
separate module. So I suggest to put the basic completion stuff used
by the new system into a module `complete' (any suggestions for a
different name?) and move the code from zle_tricky.c which isn't
really needed by `zle' and which is needed only by `compctl' into the
`compctl.c' file. The new `complete.c' would then contain the
interface stuff for the new system which is now in `compctl.c'. And
`zle_tricky.c' would contain the basic completion generation code sans 
the stuff needed by `compctl'.

On the interface side `compgen' would be removed. It would be replaced 
by implementing other mechanisms that allow us to do everything `compgen' 
can do now but using `compadd' instead. For now I'm only thinking
about enhancements to the `parameter' module (maybe this is wrong)
because parameter expansion magic can nicely be combined with
`compadd'. As far as I can see we need access to the following
information:

  - aliases - Supplying a hash for them is relatively simple, only a
      small problem with the normal/global aliases difference. Maybe
      we can solve this by using keys like `regular:foo' and
      `global:bar' or something. 
      But then, maybe we don't need this because it is so seldom used
      that we can just use `$(alias)'. And `$(disable -a)' and
      `$(enable -a)' to get at that information.
  - builtins and reserved words - Again, it may be enough to just use
      `enable' and `disable'. If not, adding small hashes for them
      should be simple (but how? with values `{en,dis}abled'? `on/off'?).
  - functions - We have already a parameter for that (which might be a 
      reason to add `aliases' once we have decided how we distinguish
      regular and global ones), the only thing we need is the
      information about whether they are enabled or not -- see above.
  - parameters - It should be enough to make the type strings available 
      with the `parameters' hash more verbose, including `special',
      `hide', probably the fact that the parameter is one of a pair of 
      tied-together parameters (we could also include the other's
      name).
  - named directories - This could easily be done with a special hash, 
      say `nameddirs' (better name?).
  - user directories - This could also be done with a special hash
      (`userdirs'?).
  - widget names - We could either use a normal array with their names 
      or a hash mapping the name to the keys the widget is bound
      to. Or we map the names to `built/user-defined'. Or both.
  - jobs - This is a bit problematic because there is so many
      information we might want to map a job number to. For the
      completion code we might want the words of the command line and
      the current state (running, suspended, ...). For other things,
      the different pids may be of interest. We could either use
      different keys for every job or we could just put all this
      information into the values (seperated by colons or something
      different, easy to parse). Suggestions?
  - history - I think a hash mapping event numbers to history lines
      should be enough here. But maybe someone can think of something
      cleverer.

Then I'd like to remove the `-y' option from `compadd'. It isn't used
in the completion system any more and it shouldn't -- because it's
incompatible with `menu-select'. I can't think of any real uses for it 
that can't be replaced by `-d' and `-ld'.

And while I'm talking about `menu-select', I can equally well ask
thiss here, too: Some time ago we had a case where `menu-select'
couldn't be used because there were multiple matches which would show
the same strings in the completion list. I made `menu-select' give up
in such cases because one wouldn't be able to access all matches from
it then. However, with the cleaner completion listing code we have now 
it wouldn't be too hard to make `menu-select' temporarily show all
matches even those which show the same string. I still think that an
otherwise sorted completion list showing one string more than once
would look weird, but maybe that's acceptable. If not, we probably
should make `menu-select' show all the information about matches in
such cases. The question is if we really want that because it may make 
the completion list much larger (and probably harder to read). Maybe
we should try to show as few information as possible. I.e. if there
are only matches with the same string-to-be-displayed that differ in
the path-suffix, then show only that (plus the strings that would be
shown otherwise, of course). I don't know how hard it would be to
collect that information, though. And what if such matches have the
same path-prefix but different `-P' prefixes? showing these directly
before the real display string would look wrong because when inserted, 
the path prefix would be between them. Hm, maybe we should separate
them with `...' or something then. That would make it even harder to
find out what to display, though. Any other suggestions?


Ok. Now I'm awaiting your comments about all this (und Stille war's,
wie ueblich ;-).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx