PATCH: $modules (was: Re: Seg fault with zmodload -u)

PATCH: $modules (was: Re: Seg fault with zmodload -u)

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> On the subject of zmodload completion, how would I prevent the 'module
> alias' description from being displayed when there are no module
> aliases - do I have to put the zmodload -A output in an array first and
> then not call the _requested line if the array is empty - or is there a
> better way?

Eh? The description for the aliases should not be displayed when there 
are no matches added for it (or none of the strings added for it match 
what's on the line). Automatically. And it works for me (using a
simple test completion function).


Anyway. Here is the change to the parameter module to report aliases
correctly in the $modules parameter. They have values of the form
`alias:<name>', where <name> is, of course, the aliased-to-name.

And the manual was still talking about `builtin' being a possible
value, although that went away when zmodload was changed to treat
linked-in modules like loaded ones.

No changes to _zmodload. If Oliver is working on the _arguments
version anyway...

Bye
 Sven

Index: Doc/Zsh/mod_parameter.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/mod_parameter.yo,v
retrieving revision 1.3
diff -u -r1.3 mod_parameter.yo
--- Doc/Zsh/mod_parameter.yo	2000/05/21 18:27:36	1.3
+++ Doc/Zsh/mod_parameter.yo	2000/08/16 09:17:39
@@ -91,9 +91,10 @@
 vindex(modules)
 item(tt(modules))(
 An associative array giving information about modules. The keys are the names
-of the modules builtin, loaded, or registered to be autoloaded. The
+of the modules loaded, registered to be autoloaded, or aliased. The
 value says which state the named module is in and is one of the
-strings tt(builtin), tt(loaded), or tt(autoloaded).
+strings `tt(loaded)', `tt(autoloaded)', or `tt(alias:)var(name)',
+where var(name) is the name the module is aliased to.
 
 Setting or unsetting keys in this array is not possible.
 )
Index: Src/Modules/parameter.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/parameter.c,v
retrieving revision 1.16
diff -u -r1.16 parameter.c
--- Src/Modules/parameter.c	2000/08/14 07:30:29	1.16
+++ Src/Modules/parameter.c	2000/08/16 09:17:40
@@ -892,7 +892,8 @@
 	    m = (Module) getdata(node);
 	    if (m->u.handle && !(m->flags & MOD_UNLOAD) &&
 		!strcmp(name, m->nam)) {
-		type = "loaded";
+		type = ((m->flags & MOD_ALIAS) ?
+			dyncat("alias:", m->u.alias) : "loaded");
 		break;
 	    }
 	}
@@ -935,6 +936,7 @@
     LinkNode node;
     Module m;
     Conddef p;
+    char *loaded = dupstring("loaded");
 
     pm.flags = PM_SCALAR | PM_READONLY;
     pm.sets.cfn = NULL;
@@ -946,12 +948,12 @@
     pm.old = NULL;
     pm.level = 0;
 
-    pm.u.str = dupstring("builtin");
-    pm.u.str = dupstring("loaded");
     for (node = firstnode(modules); node; incnode(node)) {
 	m = (Module) getdata(node);
 	if (m->u.handle && !(m->flags & MOD_UNLOAD)) {
 	    pm.nam = m->nam;
+	    pm.u.str = ((m->flags & MOD_ALIAS) ?
+			dyncat("alias:", m->u.alias) : loaded);
 	    addlinknode(done, pm.nam);
 	    func((HashNode) &pm, flags);
 	}

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: $modules (was: Re: Seg fault with zmodload -u)

[Peter Stephenson]

Sven wrote:
> Oliver Kiddle wrote:
> > On the subject of zmodload completion, how would I prevent the 'module
> > alias' description from being displayed when there are no module
> > aliases - do I have to put the zmodload -A output in an array first and
> > then not call the _requested line if the array is empty - or is there a
> > better way?
> 
> Eh? The description for the aliases should not be displayed when there 
> are no matches added for it (or none of the strings added for it match 
> what's on the line). Automatically. And it works for me (using a
> simple test completion function).

I had the same experience as Oliver before I changed _zmodload.  Could it
make a difference if the string on the line is empty?  Or that I have
different match groups listed separately?

-- 
Peter Stephenson <pws@csr.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

PATCH: _zmodload

[Oliver Kiddle]

On 16 Aug, Sven wrote:

> Oliver Kiddle wrote:
> 
> > On the subject of zmodload completion, how would I prevent the 'module
> > alias' description from being displayed when there are no module
> > aliases 
> 
> Eh? The description for the aliases should not be displayed when there 
> are no matches added for it

That was what I had thought. I've just had a closer look and the problem
was something to do with ${${(f)"$(zmodload -A)"}%% *} returning a
single blank or something when there were no aliases. It's irrelevant
now anyway.

> Anyway. Here is the change to the parameter module to report aliases
> correctly in the $modules parameter. They have values of the form
> `alias:<name>', where <name> is, of course, the aliased-to-name.
> 
> No changes to _zmodload. If Oliver is working on the _arguments
> version anyway...

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.

Shouldn't we maybe have an option to remove module aliases (-u combined
with -A) or have I missed something?

Oliver

--- Completion/Builtins/_zmodload	Fri Aug 18 11:26:53 2000
+++ Completion/Builtins/_zmodload	Fri Aug 18 16:31:09 2000
@@ -1,21 +1,46 @@
 #compdef zmodload
 
-local fl="$words[2]" expl ret=1
+local suf comp state line expl curcontext="$curcontext" ret=1
+typeset -A opt_args
+suf=()
 
-if [[ "$fl" = -*(a*u|u*a)* || "$fl" = -*a* && CURRENT -ge 4 ]]; then
-  _wanted builtins expl 'builtin command' compadd "$@" -k builtins
-elif [[ "$fl" = -*u* ]]; then
-  _wanted modules expl module compadd -k modules
-else
-  _tags files aliases
-  while _tags; do
-    _requested files expl 'module file' \
-      _files -W module_path -/g '*.(dll|s[ol])(:r)' && ret=0
-    if _requested aliases expl 'module alias'; then
-      local array
-      array=(${${(f)"$(zmodload -A)"}%% *})
-      (( $#array )) && compadd "${expl[@]}" -- $array && ret=0
-    fi
-    (( ret )) || break
-  done
+_arguments -C -A "-*" -s \
+  '(-d -e)-i[suppress error if command would do nothing]' \
+  '-u[unload module]' \
+  '(-i)-d[list or specify module dependencies]' \
+  '(-e)-a[autoload module]' \
+  '(-c -I -p -f)-b[autoload module for builtins]' \
+  '(-b -I -p -f)-c[autoload module for condition codes]' \
+  '(-b -c -p -f)-I[define infix condition names]' \
+  '(-b -c -I -f)-p[autoload module for parameters]' \
+  '(-b -c -I -p)-f[autoload module for math functions]' \
+  '(-i -u -d -a -b -c -p -f -L -A)-e[test if modules are loaded]' \
+  '(-e -u)-L[output in the form of calls to zmodload]' \
+  '(-i -u -d -a -b -c -I -p -f -e)-A[create module aliases]' \
+  '*:params:->params' && ret=0
+
+[[ $state = params ]] || return ret
+
+(( $+opt_args[-A] )) && compset -P '*=' || suf=( -S '=' )
+
+comp=( files aliases )
+if (( $+opt_args[-u] )); then
+  if (( $+opt_args[-b] || $+opt_args[-a] )); then
+    comp=( builtins )
+  else
+    comp=( loadedmodules aliases )
+  fi
 fi
+(( $+opt_args[-a] && CURRENT > 3 )) && comp=( builtins )
+
+_tags "$comp[@]"
+while _tags; do
+  _requested builtins expl 'builtin command' \
+    compadd "$@" -k builtins && ret=0
+  _requested loadedmodules expl 'loaded modules' \
+    compadd -k 'modules[(R)loaded]' && ret=0
+  _requested files expl 'module file' \
+    _files -W module_path -/g '*.(dll|s[ol])(:r)' && ret=0
+  _requested aliases expl 'module alias' \
+    compadd "$suf[@]" -k 'modules[(R)alias*]' && ret=0
+done

RE: PATCH: _zmodload

[Andrej Borsenkow]

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

This lists modules twice - once with extension and once without:

bor@itsrm2% zmodload zsh/cap
Completing module file
cap               cap.so*           clone             clone.so*       
compctl           compctl.so*       complete          complete.so*    
complist          complist.so*      computil          computil.so*    
deltochar         deltochar.so*     example           example.so*     
files             files.so*         mapfile           mapfile.so*     
mathfunc          mathfunc.so*      parameter         parameter.so*   
rlimits           rlimits.so*       sched             sched.so*       
stat              stat.so*          zftp              zftp.so*        
zle               zle.so*           zleparameter      zleparameter.so*
zprof             zprof.so*         zpty              zpty.so*        
zutil             zutil.so*                                         

-andrej

Re: PATCH: _zmodload

[Sven Wischnowsky]

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

RE: PATCH: _zmodload

[Andrej Borsenkow]

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

Or define extra entry point, load module, ask it about autoloaded objects and
unload. This should be the most portable. Or just leave it loaded assuming
that user will need it anyway.

Can it be useful for something else?

-andrej