zsh-workers
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Bug with _parameters and zmodload
Date: Thu, 2 Sep 1999 11:35:08 +0200 (MET DST)	[thread overview]
Message-ID: <199909020935.LAA02481@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Peter Stephenson's message of Wed, 01 Sep 1999 18:09:50 +0200


Peter Stephenson wrote:

> Oliver Kiddle wrote:
> > When I upgraded to 3.1.6-pws-2 (from 3.1.6-test-2 - I've been busy recently s
> > o haven't upgraded for a while), I got a number of error messages of the foll
> > owing form:
> > 
> > _parameters: mapfile: autoload failed [43]
> > 
> > I get it for each of parameters, functions, options, commands and mapfile the
> >  first time I try to expand a variable after running zsh.
> 
> This should fix this part.  The modules were trying to unset any existing
> parameters when they installed their own.  The existing parameters were the
> autoloadable ones, and it tried to autoload the parameter to unset it, which
> it was already in the middle of doing so it couldn't.  The simplest fix is
> to retrieve the existing param struct without autoloading and unset that.

This didn't work for me, I still got the error message. The changed
test in params.c fixed that.
Then I changed the parameter module to report `undefined' parameters
like `typeset' does.

> I haven't touched the completion functions.  Probably there's no harm in
> _parameters loading the parameter module to use to check the parameters,
> since if it's autoloadable that should mean it's available for use in this
> sort of context, but that's different from the real problem.

Yes. I didn't do that because we don't have a easy way to find out if
a parameter/builtin/whatever is defined to be autoloaded (and I didn't 
want to fiddle with ${$(zmodload -ap)}).

Otherwise, I'm with Oliver here -- modules shouldn't be loaded just
because someone does `$<TAB>'. The hunks in `_parameters' should make
this.

Oliver Kiddle wrote:

> Another unrelated problem I have found is that the completion matching control to complete partial directories doesn't work when variables are used:
> I'd expect:
> cd $code[ai]/R/drop.1.34<tab>
> to complete to:
> cd $code[ai]/Releases/drop.1.34.0.rel/
> but it doesn't.

The patch also contains some hunks in `_path_files' which contain my
first attempt for this. Note that partial paths are only completed
after the parameter expansion (i.e. `f/$foo/b<TAB>' doesn't work if
`f' is only a prefix).

Bye
 Sven

diff -u os/params.c Src/params.c
--- os/params.c	Thu Sep  2 09:15:59 1999
+++ Src/params.c	Thu Sep  2 10:38:30 1999
@@ -292,7 +292,7 @@
 	if (!load_module(mn))
 	    return NULL;
 	hn = gethashnode2(ht, nam);
-	if (((Param) hn) == pm) {
+	if (((Param) hn) == pm && (pm->flags & PM_AUTOLOAD)) {
 	    pm->flags &= ~PM_AUTOLOAD;
 	    zwarnnam(nam, "autoload failed", NULL, 0);
 	}
diff -u os/Modules/parameter.c Src/Modules/parameter.c
--- os/Modules/parameter.c	Thu Sep  2 10:42:03 1999
+++ Src/Modules/parameter.c	Thu Sep  2 11:23:17 1999
@@ -83,6 +83,9 @@
     int f = pm->flags;
 
     if (!(f & PM_UNSET)) {
+	if (pm->flags & PM_AUTOLOAD)
+	    return dupstring("undefined");
+
 	switch (PM_TYPE(f)) {
 	case PM_SCALAR:  val = "scalar"; break;
 	case PM_ARRAY:   val = "array"; break;
diff -u -r Completion.old/Core/_parameters Completion/Core/_parameters
--- Completion.old/Core/_parameters	Wed Sep  1 14:24:54 1999
+++ Completion/Core/_parameters	Thu Sep  2 10:58:04 1999
@@ -27,18 +27,21 @@
 
 _description expl parameter
 
-if zmodload -e parameter; then
-  setopt localoptions extendedglob
-  pars=( ${(k)parameters[(R)^*local*]} )
-else
-  pars=( ${${${(f)"$(typeset +)"}:#*local *}##* } )
-fi
-
 if [[ -n "$slash" && -o autoparamslash ]]; then
   local i dirs nodirs ret=1
 
   dirs=()
   nodirs=()
+
+  if zmodload -e parameter; then
+    setopt localoptions extendedglob
+    nodirs=( ${(k)parameters[(R)undefined]} )
+    pars=( ${(k)parameters[(R)^*(local|undefined)*]} )
+  else
+    nodirs=( ${${(M)${(f)"$(typeset +)"}:#undefined *}##* } )
+    pars=( ${${${(f)"$(typeset +)"}:#*(local|undefined) *}##* } )
+  fi
+
   for i in $pars; do
     if [[ -d "${(P)i}" ]]; then
       dirs=( $dirs $i )
@@ -57,6 +60,13 @@
 
   return ret
 else
+  if zmodload -e parameter; then
+    setopt localoptions extendedglob
+    pars=( ${(k)parameters[(R)^*local*]} )
+  else
+    pars=( ${${${(f)"$(typeset +)"}:#*local *}##* } )
+  fi
+
   if [[ "$slash" = normal ]]; then
     compadd -S "$suf" -r ' [:' "$expl[@]" "$@" - $pars
   elif [[ "$slash" = brace ]]; then
diff -u -r Completion.old/Core/_path_files Completion/Core/_path_files
--- Completion.old/Core/_path_files	Wed Sep  1 14:24:54 1999
+++ Completion/Core/_path_files	Thu Sep  2 11:11:53 1999
@@ -173,6 +173,22 @@
   orig="${orig#*/}"
   donepath=''
   prepaths=( '' )
+elif [[ "$pre" = *\$*/* ]]; then
+
+  # If there is a parameter expansion in the word from the line, we try
+  # to complete the beast by expanding the prefix and completing anything
+  # after the first slash after the parameter expansion.
+  # This fails for things like `f/$foo/b/<TAB>' where the first `f' is
+  # meant as a partial path.
+
+  linepath="${(M)pre##*\$[^/]##/}"
+  realpath=${(e)~linepath}
+  [[ "$realpath" = "$linepath" ]] && return 1
+  pre="${pre#${linepath}}"
+  i="${#linepath//[^\\/]}"
+  orig="${orig[1,(in:i:)/][1,-2]}"
+  donepath=''
+  prepaths=( '' )
 else
   # If the string does not start with a `~' we don't remove a prefix from the
   # string.

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


             reply	other threads:[~1999-09-02  9:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-09-02  9:35 Sven Wischnowsky [this message]
1999-09-02  9:50 ` Why is not parameter autoloaded? " Andrej Borsenkow
  -- strict thread matches above, loose matches on Subject: below --
1999-09-01 16:01 Oliver Kiddle
1999-09-01 16:09 ` Peter Stephenson
1999-09-02  8:53   ` Peter Stephenson

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=199909020935.LAA02481@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).