From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: _zmodload
Date: Mon, 21 Aug 2000 10:00:18 +0200 (MET DST) [thread overview]
Message-ID: <200008210800.KAA00733@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Oliver Kiddle's message of Fri, 18 Aug 2000 15:43:18 +0100
Oliver Kiddle wrote:
> ...
>
> Well here is the _arguments version and I've also tried to make use of
> the $modules parameter where possible. Is my strategy of retricting the
> arguments to _tags and then completing everything in the while _tags
> loop okay? It seems to work and was the easiest way I could find to
> handle _zmodload seeing as it has all the flags first.
Yes, that's ok. Of course, one could use multiple loops when _zmodload
is changed to complete the things needed by zmodload. E.g. completion
after `zmodload -ac foo <TAB>' completes builtins, which is wrong. The
same for -ap etc.
Another questionable completion is `zmodload -A <TAB>'. That completes
modules files, but we need an alias name (something we can't really
complete at that point, because the user almost certainly wants a new
alias name).
And those builtins completed... offering the builtins currently
defined is a simple solution for a hard problem, but will be wrong in
most cases. For the modules we have currently, the builtins could be
derived with something like `nm <module> | grep bin_'. Unfortunately,
this isn't guaranteed to be correct and won't work for autoloaded
parameters, conditions and so on anyway. Maybe trying to find a .mdd
file and looking at it would be a better solution. Or maybe giving up
and doing what _zmodload does now... sigh.
The patch makes the return value built be used.
Bye
Sven
Index: Completion/Builtins/_zmodload
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Builtins/_zmodload,v
retrieving revision 1.6
diff -u -r1.6 _zmodload
--- Completion/Builtins/_zmodload 2000/08/18 17:21:58 1.6
+++ Completion/Builtins/_zmodload 2000/08/21 07:59:44
@@ -44,3 +44,5 @@
_requested aliases expl 'module alias' \
compadd "$suf[@]" -k 'modules[(R)alias*]' && ret=0
done
+
+return ret
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-08-21 8:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-21 8:00 Sven Wischnowsky [this message]
2000-08-21 8:34 ` Andrej Borsenkow
-- strict thread matches above, loose matches on Subject: below --
2000-08-16 9:23 PATCH: $modules (was: Re: Seg fault with zmodload -u) Sven Wischnowsky
2000-08-18 14:43 ` PATCH: _zmodload Oliver Kiddle
2000-08-21 6:04 ` Andrej Borsenkow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200008210800.KAA00733@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).