From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 825 invoked from network); 1 Aug 2000 09:00:55 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Aug 2000 09:00:55 -0000 Received: (qmail 4116 invoked by alias); 1 Aug 2000 09:00:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12454 Received: (qmail 4109 invoked from network); 1 Aug 2000 09:00:21 -0000 Date: Tue, 1 Aug 2000 11:00:16 +0200 (MET DST) Message-Id: <200008010900.LAA06432@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk Subject: Open bugs and questions? 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@informatik.hu-berlin.de