Re: PATCH: Re: Completion and global aliases

Re: PATCH: Re: Completion and global aliases

[Sven Wischnowsky]

Peter Stephenson wrote:

> And it looks like we'd better do something with options, too.  There is the
> code from compinstall, but then there's always the possibility we could
> make it a function as Andrej keeps suggesting.  compinstall could still
> work out the path to the completion functions and make it get passed down
> to compinit, and if compdump was also a function it wouldn't need searching
> for, which removes one headache.

And to avoid having them take up memory we could put (the equivalent
of) `unfunction compinit; autoload compinit' at their ends.

(At least the memory thing was the only reason why I was against
turning them into functions and I hadn't thought of this before... I'm 
a bit slow sometimes.)

Bye
 Sven


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

RE: PATCH: Re: Completion and global aliases

[Andrej Borsenkow]

>
> And to avoid having them take up memory we could put (the equivalent
> of) `unfunction compinit; autoload compinit' at their ends.
>
> (At least the memory thing was the only reason why I was against
> turning them into functions and I hadn't thought of this before... I'm
> a bit slow sometimes.)
>

Well, the function was initial idea ... and I admit, it was probably wrong
as well. The problem with functions is, they need to be defined somehow ...
that returns us to the same problem, how do I find where this function
lives.

My goal was actually to make new completion (or should I better use function
based completion?) to be as easy to setup as compctl. FBC has great
advantage over compctl - as it stands now, ZSH already comes with handfull
of useful completions that are already even installed :-). The only problem
is to tell it to use them.

As it seems, the possibilities are:

 - predefine compinit as autoloaded function if --enable-fndir is specified
 - create a builtin that will source compinit
 - provide COMPINIT (or eqv) parameter (read-only) to hold the full pathname
of compinit. That is probably the least evil.

In any case, if compinit remains sourced script, I would suggest moving it
away from $fpath (e.g. in ${datadir}/zsh). How many users have 'autoload
$^fpath/*(:t)' as suggested by readme? It is probably not nice having
something else as functions in $fpath.

And related - placement of dump file. Again, now, when most completion
functions are installed in system-wide location - what is the reason to try
put dump file in the same dir as compinit? Why not simply dump it in $HOME
by default? I mean, that check will probably fail in 99% of all
installations.

/andrej

Re: PATCH: Re: Completion and global aliases

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> As it seems, the possibilities are:
> 
>  - predefine compinit as autoloaded function if --enable-fndir is specified
>  - create a builtin that will source compinit
>  - provide COMPINIT (or eqv) parameter (read-only) to hold the full pathname
> of compinit. That is probably the least evil.

I don't see that it's that hard to tell a user `add the following to your
.zshrc', or have it in /etc/zshrc, or let them run compinstall.  Maybe the
manual could provide a simple one-line suggestion, though, for anyone not
wanting to run compinstall  --- possibly the manual could be altered to
contain the real location of compinit, but that will require more remaking
than seems a good idea.

> In any case, if compinit remains sourced script, I would suggest moving it
> away from $fpath (e.g. in ${datadir}/zsh). How many users have 'autoload
> $^fpath/*(:t)' as suggested by readme? It is probably not nice having
> something else as functions in $fpath.

(Autoloading everything in $fpath could conflict with Bart's `autoload -U'
suggestion --- although I presume that first autoloading without -U, then
with, will add the NOALIASES flag.)  This complicates installation,
however, and Oliver was suggesting he'd prefer the directory structure
retained.  I haven't worked out a simple way of doing all this.

> And related - placement of dump file. Again, now, when most completion
> functions are installed in system-wide location - what is the reason to try
> put dump file in the same dir as compinit? Why not simply dump it in $HOME
> by default? I mean, that check will probably fail in 99% of all
> installations.

Yes, it may be too heavily biassed towards people developing rather than
using the system.

I don't know when I'll get a chance to look at this, I have about 50
different things to do at once, so if someone has a way of simplifying all
this so much the better.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: Re: Completion and global aliases

[Bart Schaefer]

On Jun 9, 11:01am, Peter Stephenson wrote:
} Subject: Re: PATCH: Re: Completion and global aliases
}
} manual could provide a simple one-line suggestion, though, for anyone not
} wanting to run compinstall  --- possibly the manual could be altered to
} contain the real location of compinit, but that will require more remaking

I don't think remaking is a big issue, but I've always thought it was silly
to have manual pages attempt to reflect local install paths.  There's always
somebody who shuffles things around after the fact or tries to share manual
pages over NFS (or over the web!), rendering compile-time patching useless.

} (Autoloading everything in $fpath could conflict with Bart's `autoload -U'
} suggestion --- although I presume that first autoloading without -U, then
} with, will add the NOALIASES flag.)

Yes, that works.

} This complicates installation,
} however, and Oliver was suggesting he'd prefer the directory structure
} retained.  I haven't worked out a simple way of doing all this.

Just a random thought ... the installation process has just copied a zsh
binary into place, right?  So you can write a zsh function to install the
rest of the zsh functions, and feed it to the zsh that you just built ...

(Except that doesn't work when cross-compiling, sigh.)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

RE: PATCH: Re: Completion and global aliases

[Andrej Borsenkow]

>
> On Jun 9, 11:01am, Peter Stephenson wrote:
> } Subject: Re: PATCH: Re: Completion and global aliases
> }
> } manual could provide a simple one-line suggestion, though, for
> anyone not
> } wanting to run compinstall  --- possibly the manual could be altered to
> } contain the real location of compinit, but that will require
> more remaking
>
> I don't think remaking is a big issue, but I've always thought it
> was silly
> to have manual pages attempt to reflect local install paths.
> There's always
> somebody who shuffles things around after the fact or tries to
> share manual
> pages over NFS (or over the web!), rendering compile-time
> patching useless.
>

Yes. It is exactly for this reason I keep suggesting a *builtin* (to the
extent) way to initalize completion. I do not like the idea to rewrite rc
files every time directory layout changes for whatever reason. And if I have
single home dir, and zsh is installed in different locations on every
system - maintaining rc becomes a nightmare.

/andrej

Completion and global aliases

[Wayne Davison]

I figured out what was going wrong with getting completion running
with my setup.  The running of the completion code is apparently
being affected by all my global aliases.  I happen to have a global
alias named "X" that is getting expanded by a completion script and
is causing a syntax error.

This brings up the issue:  shouldn't completion really be running in
a pre-defined environment, not the user's current environment?
I.e.  I don't want all my interactive options, aliases, etc. to
affect the running of the scripts.

It seems to me like we need the code that runs the completion
scripts to switch over to its own options/aliases/whatever-else
and then switch back when it finishes.

..wayne..

PATCH: Re: Completion and global aliases

[Bart Schaefer]

On Jun 8,  7:43pm, Wayne Davison wrote:
} Subject: Completion and global aliases
}
} It seems to me like we need the code that runs the completion
} scripts to switch over to its own options/aliases/whatever-else
} and then switch back when it finishes.

I was about to say that the right thing would be to load all completion
code (i.e. run compinit) before any aliases are defined, but that would
still leave any autoloaded functions to get mishandled.

So how about this:  We add an option to `autoload' to mark the function
as immune to alias expansion.  It's a small change to execautofn() to
recognize this flag and temporarily set the noaliases global.  Then it's
just up to `compinit' to deal with its own problems, maybe by doing some
smart things with `disable -a'.

The following patch implements `autoload -U ...' for this.  Hmm, I didn't
change `functions' to output anything for "unaliased" state; should it?

Index: Completion/Core/compdump
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Completion/Core/compdump,v
retrieving revision 1.2
diff -u -r1.2 compdump
--- compdump	1999/04/20 16:13:52	1.2
+++ compdump	1999/06/09 06:06:57
@@ -74,7 +74,7 @@
 # print them out:  about five to a line looks neat
 
 while (( $#_d_als )); do
-  print -n autoload
+  print -n autoload -U
   for (( _i = 0; _i < 5; _i++ )); do
     if (( $#_d_als )); then
       print -n " $_d_als[1]"
Index: Completion/Core/compinit
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Completion/Core/compinit,v
retrieving revision 1.10
diff -u -r1.10 compinit
--- compinit	1999/06/08 15:01:40	1.10
+++ compinit	1999/06/09 05:28:23
@@ -194,7 +194,7 @@
     # and probably do autoloading.
 
     func="$1"
-    [[ -n "$autol" ]] && autoload "$func"
+    [[ -n "$autol" ]] && autoload -U "$func"
     shift
 
     case "$type" in
@@ -363,7 +363,7 @@
 	fi
 	;;
       (\#autoload)
-	autoload ${_i_file:t}
+	autoload -U ${_i_file:t}
 	;;
       esac
     done
Index: Doc/Zsh/builtins.yo
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Doc/Zsh/builtins.yo,v
retrieving revision 1.22
diff -u -r1.22 builtins.yo
--- builtins.yo	1999/06/07 05:42:42	1.22
+++ builtins.yo	1999/06/09 06:13:15
@@ -981,12 +981,13 @@
 )
 item(tt(-f))(
 The names refer to functions rather than parameters.  No assignments
-can be made, and the only other valid flags are tt(-t)
-and tt(-u).  The flag tt(-t) turns on execution tracing for this
-function.  The flag tt(-u) causes this function to be marked
-for autoloading.  The tt(fpath) parameter will be searched to find the
-function definition when the function is first referenced; see
-noderef(Functions).
+can be made, and the only other valid flags are tt(-t), tt(-u) and
+tt(-U).  The flag tt(-t) turns on execution tracing for this
+function.  The tt(-u) and tt(-U) flags cause the function to be
+marked for autoloading; tt(-U) also causes alias expansion to be
+suppressed when the function is loaded.  The tt(fpath) parameter
+will be searched to find the function definition when the function
+is first referenced; see noderef(Functions).
 )
 item(tt(-i))(
 Use an internal integer representation.  If var(n) is nonzero it
Index: Src/builtin.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/builtin.c,v
retrieving revision 1.28
diff -u -r1.28 builtin.c
--- builtin.c	1999/05/31 19:06:05	1.28
+++ builtin.c	1999/06/09 05:22:39
@@ -43,7 +43,7 @@
     BUILTIN(".", BINF_PSPECIAL, bin_dot, 1, -1, 0, NULL, NULL),
     BUILTIN(":", BINF_PSPECIAL, bin_true, 0, -1, 0, NULL, NULL),
     BUILTIN("alias", BINF_MAGICEQUALS, bin_alias, 0, -1, 0, "Lgmr", NULL),
-    BUILTIN("autoload", BINF_TYPEOPTS, bin_functions, 0, -1, 0, "t", "u"),
+    BUILTIN("autoload", BINF_TYPEOPTS, bin_functions, 0, -1, 0, "tU", "u"),
     BUILTIN("bg", 0, bin_fg, 0, -1, BIN_BG, NULL, NULL),
     BUILTIN("break", BINF_PSPECIAL, bin_break, 0, 1, BIN_BREAK, NULL, NULL),
     BUILTIN("bye", 0, bin_break, 0, 1, BIN_EXIT, NULL, NULL),
@@ -64,7 +64,7 @@
     BUILTIN("false", 0, bin_false, 0, -1, 0, NULL, NULL),
     BUILTIN("fc", BINF_FCOPTS, bin_fc, 0, -1, BIN_FC, "nlreIRWAdDfEim", NULL),
     BUILTIN("fg", 0, bin_fg, 0, -1, BIN_FG, NULL, NULL),
-    BUILTIN("functions", BINF_TYPEOPTS, bin_functions, 0, -1, 0, "mtu", NULL),
+    BUILTIN("functions", BINF_TYPEOPTS, bin_functions, 0, -1, 0, "mtuU", NULL),
     BUILTIN("getln", 0, bin_read, 0, -1, 0, "ecnAlE", "zr"),
     BUILTIN("getopts", 0, bin_getopts, 2, -1, 0, NULL, NULL),
     BUILTIN("hash", BINF_MAGICEQUALS, bin_hash, 0, -1, 0, "dfmrv", NULL),
@@ -1824,17 +1824,18 @@
     int on = 0, off = 0;
 
     /* Do we have any flags defined? */
-    if (ops['u'] || ops['t']) {
-	if (ops['u'] == 1)
-	    on |= PM_UNDEFINED;
-	else if (ops['u'] == 2)
-	    off |= PM_UNDEFINED;
-
-	if (ops['t'] == 1)
-	    on |= PM_TAGGED;
-	else if (ops['t'] == 2)
-	    off |= PM_TAGGED;
-    }
+    if (ops['u'] == 1)
+	on |= PM_UNDEFINED;
+    else if (ops['u'] == 2)
+	off |= PM_UNDEFINED;
+    if (ops['U'] == 1)
+	on |= PM_UNALIASED|PM_UNDEFINED;
+    else if (ops['U'] == 2)
+	off |= PM_UNALIASED;
+    if (ops['t'] == 1)
+	on |= PM_TAGGED;
+    else if (ops['t'] == 2)
+	off |= PM_TAGGED;
 
     if (off & PM_UNDEFINED) {
 	zwarnnam(name, "invalid option(s)", NULL, 0);
Index: Src/exec.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/exec.c,v
retrieving revision 1.22
diff -u -r1.22 exec.c
--- exec.c	1999/05/29 10:02:05	1.22
+++ exec.c	1999/06/09 05:15:40
@@ -2752,7 +2752,13 @@
 execautofn(Cmd cmd)
 {
     Shfunc shf = cmd->u.autofn->shf;
-    List l = getfpfunc(shf->nam);
+    int noalias = noaliases;
+    List l;
+
+    noaliases = (shf->flags & PM_UNALIASED);
+    l = getfpfunc(shf->nam);
+    noaliases = noalias;
+
     if(l == &dummy_list) {
 	zerr("%s: function definition file not found", shf->nam, 0);
 	return 1;
Index: Src/zsh.h
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-3.1/Src/zsh.h,v
retrieving revision 1.26
diff -u -r1.26 zsh.h
--- zsh.h	1999/05/31 19:06:06	1.26
+++ zsh.h	1999/06/09 04:50:07
@@ -948,7 +948,12 @@
 #define PM_READONLY	(1<<8)	/* readonly                                   */
 #define PM_TAGGED	(1<<9)	/* tagged                                     */
 #define PM_EXPORTED	(1<<10)	/* exported                                   */
+
+/* The following are the same since they *
+ * both represent -U option to typeset   */
 #define PM_UNIQUE	(1<<11)	/* remove duplicates                          */
+#define PM_UNALIASED	(1<<11)	/* do not expand aliases when autoloading     */
+
 #define PM_TIED 	(1<<12)	/* array tied to colon-path or v.v. */
 #define PM_SPECIAL	(1<<13) /* special builtin parameter                  */
 #define PM_DONTIMPORT	(1<<14)	/* do not import this variable                */

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: Re: Completion and global aliases

[Peter Stephenson]

"Bart Schaefer" wrote:
> So how about this:  We add an option to `autoload' to mark the function
> as immune to alias expansion.  It's a small change to execautofn() to
> recognize this flag and temporarily set the noaliases global.  Then it's
> just up to `compinit' to deal with its own problems, maybe by doing some
> smart things with `disable -a'.

And it looks like we'd better do something with options, too.  There is the
code from compinstall, but then there's always the possibility we could
make it a function as Andrej keeps suggesting.  compinstall could still
work out the path to the completion functions and make it get passed down
to compinit, and if compdump was also a function it wouldn't need searching
for, which removes one headache.

> The following patch implements `autoload -U ...' for this.  Hmm, I didn't
> change `functions' to output anything for "unaliased" state; should it?

It's hard to know where to put it that isn't going to confuse matters,
either because someone has code to search for `undefined', or because the
next word is taken as the function name, etc.  Maybe as long as `functions
-uU' works OK it's good enough.

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

Re: PATCH: Re: Completion and global aliases

[Bart Schaefer]

On Jun 9,  9:48am, Peter Stephenson wrote:
} Subject: Re: PATCH: Re: Completion and global aliases
}
} "Bart Schaefer" wrote:
} > The following patch implements `autoload -U ...' for this.  Hmm, I didn't
} > change `functions' to output anything for "unaliased" state; should it?
} 
} It's hard to know where to put it that isn't going to confuse matters,
} either because someone has code to search for `undefined', or because the
} next word is taken as the function name, etc.  Maybe as long as `functions
} -uU' works OK it's good enough.

Unfortunately, "functions -uU" can't do the "right" thing because functions
with the unaliased flag also have the undefined flag, and scanhashtable()
prints nodes that have any of the requested flags (not nodes that have all
of them).  Maybe the following is OK:

Index: Src/builtin.c
***************
*** 1846,1851 ****
--- 1846,1853 ----
       * are given, we will print only functions containing these  *
       * flags, else we'll print them all.                         */
      if (!*argv) {
+ 	if (ops['U'] && !ops['u'])
+ 	    on &= ~PM_UNDEFINED;
  	scanhashtable(shfunctab, 1, on|off, DISABLED, shfunctab->printnode, 0);
  	return 0;
      }

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com