Open bugs and questions?

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Semester-holiday has definitely begun now. So, does anyone have a list
of unfixed bugs and open questions? Bart?

Here are the things I know about, none of these is a real
show-stopper, I think:

12354
  Probably add C-support for _multi_parts. Very low priority.

12344, 12350, 12382
  Make `_arguments --' use the short options, too?
  And make it prefer a user-supplied description if there is one (and
  a automatically found one).
  Not too high priority, either.

12225
  The return value of _arguments with `->state' actions doesn't tell
  if options were completed. This is really only a problem if the
  states are handled in a loop after the call to _arguments. And only
  for some kinds of loops, that don't check if matches were generated.
  I'm not sure how to make this more user-friendly (_arguments-calling-
  function-friendly, that is), so that its easy to find out if
  _arguments didn't add anything or if it added options (and at least
  one of them matched what's on the line).
  Low priorit, too, because it's a very special problem that can be
  solved in the calling function using $compstate[nmatches].

12054, 12071
  There is no way to handle ^D at the beginning of the line with a
  widget, because the zle main loop deals with it directly.
  There weren't any other responses, but I still think it would be
  nice to be able to redefine this behaviour with a widget (would make 
  the behaviour more consistent). But then we would have to either
  change the widgets that are now bound to ^D to handle IGNORE_EOF
  (breaking the setup for people who have it bound to something
  different) or we have to define widgets that handle IGNORE_EOF and
  otherwise do the things the ^D-bound widgets do now (breaking the
  setup for people who have re-bound ^D or bound them to the default).
  Very ugly, does anyone see a good solution?

..., 11973
  Completion after `{a,b}'. Urgh. I don't want to think about this
  before 4.0. After 4.0, I want to think about moving more of the
  completion-setup and -finalisation code into shell code. That would
  give us a better starting point to handle this.

11399, 11400, 11413, 11428
  Context names for styles not used by the completion system
  itself. More specifically, for function that call the completion
  system, but have other styles used directly. And where to document
  them.
  As far as I can see, this is currently only of interest for
  prediction (and probably incremental completion). So maybe we should 
  just use `:predict:...' and `:incremental:...' there and add a
  section to the zle manual for widgets implemented as shell functions 
  where we can describe the contexts and styles.

11465
  Interrupting builtins. E.g. with `cmd1 | builtin ; cmd2' a ^C should 
  keep cmd2 from being run.
  I still don't have an idea how to solve this.



And, directly before 4.0: moving functions (11097, 11099, 11104,
11108), but also including the compctl stuff in Functions/Misc (and
what about the StartupFiles?).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx