* Re: PATCH: Re: Completion and global aliases
@ 1999-06-09 8:53 Sven Wischnowsky
1999-06-09 9:17 ` Andrej Borsenkow
0 siblings, 1 reply; 8+ messages in thread
From: Sven Wischnowsky @ 1999-06-09 8:53 UTC (permalink / raw)
To: zsh-workers
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: PATCH: Re: Completion and global aliases 1999-06-09 8:53 PATCH: Re: Completion and global aliases Sven Wischnowsky @ 1999-06-09 9:17 ` Andrej Borsenkow 1999-06-09 9:01 ` Peter Stephenson 0 siblings, 1 reply; 8+ messages in thread From: Andrej Borsenkow @ 1999-06-09 9:17 UTC (permalink / raw) To: Sven Wischnowsky, zsh-workers > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: Re: Completion and global aliases 1999-06-09 9:17 ` Andrej Borsenkow @ 1999-06-09 9:01 ` Peter Stephenson 1999-06-09 16:49 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Peter Stephenson @ 1999-06-09 9:01 UTC (permalink / raw) To: zsh-workers "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: Re: Completion and global aliases 1999-06-09 9:01 ` Peter Stephenson @ 1999-06-09 16:49 ` Bart Schaefer 1999-06-09 17:05 ` Andrej Borsenkow 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 1999-06-09 16:49 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: PATCH: Re: Completion and global aliases 1999-06-09 16:49 ` Bart Schaefer @ 1999-06-09 17:05 ` Andrej Borsenkow 0 siblings, 0 replies; 8+ messages in thread From: Andrej Borsenkow @ 1999-06-09 17:05 UTC (permalink / raw) To: Bart Schaefer, zsh-workers > > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Completion and global aliases @ 1999-06-09 2:43 Wayne Davison 1999-06-09 6:15 ` PATCH: " Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Wayne Davison @ 1999-06-09 2:43 UTC (permalink / raw) To: ZSH workers mailing list 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.. ^ permalink raw reply [flat|nested] 8+ messages in thread
* PATCH: Re: Completion and global aliases 1999-06-09 2:43 Wayne Davison @ 1999-06-09 6:15 ` Bart Schaefer 1999-06-09 7:48 ` Peter Stephenson 0 siblings, 1 reply; 8+ messages in thread From: Bart Schaefer @ 1999-06-09 6:15 UTC (permalink / raw) To: Wayne Davison, ZSH workers mailing list 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: Re: Completion and global aliases 1999-06-09 6:15 ` PATCH: " Bart Schaefer @ 1999-06-09 7:48 ` Peter Stephenson 1999-06-09 15:40 ` Bart Schaefer 0 siblings, 1 reply; 8+ messages in thread From: Peter Stephenson @ 1999-06-09 7:48 UTC (permalink / raw) To: ZSH workers mailing list "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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: PATCH: Re: Completion and global aliases 1999-06-09 7:48 ` Peter Stephenson @ 1999-06-09 15:40 ` Bart Schaefer 0 siblings, 0 replies; 8+ messages in thread From: Bart Schaefer @ 1999-06-09 15:40 UTC (permalink / raw) To: ZSH workers mailing list 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1999-06-09 17:06 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-06-09 8:53 PATCH: Re: Completion and global aliases Sven Wischnowsky 1999-06-09 9:17 ` Andrej Borsenkow 1999-06-09 9:01 ` Peter Stephenson 1999-06-09 16:49 ` Bart Schaefer 1999-06-09 17:05 ` Andrej Borsenkow -- strict thread matches above, loose matches on Subject: below -- 1999-06-09 2:43 Wayne Davison 1999-06-09 6:15 ` PATCH: " Bart Schaefer 1999-06-09 7:48 ` Peter Stephenson 1999-06-09 15:40 ` Bart Schaefer
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).