Function installation

Function installation

[Peter Stephenson]

I've written a patch for installing the functions from the source
distribution, but as it involves moving files between directories it's not
very convenient to post and instead I'll leave it for pws-21.

Here's what I've done:

* --enable-fndir=directory allows you to specify a function installation
  directory; default is ${datadir}/zsh-fns, almost certainly
  ${prefix}/share/zsh-fns

* The given directory is compiled as the default value for $fpath/$FPATH

* `make install' or `make install.fns' will install all functions from
  under Completion and Functions into that directory, `make uninstall' or
  `make uninstall.fns' will delete them.

* --disable-fndir or --enable-fndir=no turns off both installation of
  functions and the default $fpath/$FPATH

* Functions now contains two subdirectories, Misc and Zftp, where all the
  functions themselves live (parallels Completion, and allows $dir/* for
  installation so as not to have to list all files in the Makefile).

Any views on overwriting behaviour?

- always overwrite existing installed functions

- never overwrite

- compare each file with the installed version, if it differs move the old
  one to $file.old (unconditionally) and install the new one --- slow but
  safer

- something devilishly clever

-- 
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: Function installation

[Wayne Davison]

On Mon, 7 Jun 1999, Peter Stephenson wrote:
> I've written a patch for installing the functions from the source
> distribution

That reminds me.  Has anyone else run into a problem using compinit
with the "no_unset" option enabled?  After getting errors on lines
57 and 53, I just unset the option before the sourcing of compinit
in my zshrc file, and reset it after it was done.

[I'm only just now finding some time to try out the new completion
stuff in 3.1.x, and so far (with just a little bit of twiddling) I
haven't gotten it to work.  I'll have more time to play with it
later on.]

> Any views on overwriting behaviour?
> - compare each file with the installed version, if it differs move
>   the old one to $file.old (unconditionally) and install the new
>   one --- slow but safer

Something like this sounds cool.

> - something devilishly clever

How about automating a "cvs import" procedure that maintains a cvs
archive of the files for you, and merges your local changes into the
new releases using a cvs checkout?  That would at least be devilish,
if not clever.  :-)

..wayne..

Re: Function installation

[Peter Stephenson]

Wayne Davison wrote:
> On Mon, 7 Jun 1999, Peter Stephenson wrote:
> > I've written a patch for installing the functions from the source
> > distribution
> 
> That reminds me.  Has anyone else run into a problem using compinit
> with the "no_unset" option enabled?  After getting errors on lines
> 57 and 53, I just unset the option before the sourcing of compinit
> in my zshrc file, and reset it after it was done.

After the patch, compinit seems to run with zsh -f and setopt nounset.

> [I'm only just now finding some time to try out the new completion
> stuff in 3.1.x, and so far (with just a little bit of twiddling) I
> haven't gotten it to work.  I'll have more time to play with it
> later on.]

Completion seemed to work OK, too, after the above, but it's possible
(likely, I would say) some of the functions aren't very happy with
nounset.

--- Completion/Core/compinit.unset	Fri Jun  4 15:19:08 1999
+++ Completion/Core/compinit	Mon Jun  7 10:54:15 1999
@@ -50,7 +50,7 @@
 _i_fdir=''
 _i_dumpfile=''
 _i_autodump=0
-while [[ $1 = -[df] ]]; do
+while [[ $# -gt 0 && $1 = -[df] ]]; do
   if [[ "$1" = -d ]]; then
     _i_autodump=1
     shift

-- 
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: Function installation

[Wayne Davison]

On Mon, 7 Jun 1999, Peter Stephenson wrote:
> --- Completion/Core/compinit.unset	Fri Jun  4 15:19:08 1999
> +++ Completion/Core/compinit	Mon Jun  7 10:54:15 1999

That fixes the main loop, but not a trailing -d option:

Index: Completion/Core/compinit
--- zsh-3.1.5-pws-20/Completion/Core/compinit	Mon Jun  7 09:29:09 1999
+++ ./Completion/Core/compinit	Mon Jun  7 09:28:40 1999
@@ -54,7 +54,7 @@
   if [[ "$1" = -d ]]; then
     _i_autodump=1
     shift
-    if [[ -n "$1" && "$1" != -[df] ]]; then
+    if [[ $# -gt 0 && "$1" != -[df] ]]; then
       _i_dumpfile="$1"
       shift
     fi

I think a better fix would be to make "no_unset" only apply to typed
commands, not scripts (that's the only place I'm interested in it).
Hmm, I wonder if it would be possible to kludge that up using preexec
and precmd?

Another potential fix would be to have an easy way to set a local,
per-script option (not per-function).  If that's possible, I didn't
see it.

..wayne..

RE: Function installation

[Andrej Borsenkow]

>
> * --enable-fndir=directory allows you to specify a function installation
>   directory; default is ${datadir}/zsh-fns, almost certainly
>   ${prefix}/share/zsh-fns
>

Peter, are you so fond of cryptic names? Why not simply {datadir}/zsh or, at
least, ${datadir}/zsh/functions ? (In hope, that may be some more stuff will
evtl go into base dir).

> * The given directory is compiled as the default value for $fpath/$FPATH
>
> * `make install' or `make install.fns' will install all functions from
>   under Completion and Functions into that directory, `make uninstall' or
>   `make uninstall.fns' will delete them.
>

May I argue that? Most functions in Functions are hardly more than examples;
some of them are outdated (who needs cdmatch/multi_comp with new
completion?). I believe, this choice should be left to those, who maintains
ZSH distributions (RPMs), and it should default to off for source install.

The same with new completion stuff. The files, that must be installed (if at
all) are Core, Base and (probably) Builtins. Without them new completion
won't run. But again, I don't want to see a bunch of completions for GNUish
systems here - I don't use GNU tools.

So. I'd prefer the way to separately install Completion and Functions, with
Functions being off by default. And to select, what part is installed.

Peter, what about something like this:

use variables like FUNCTIONS_INCLUDE and/or FUNCTIONS_EXCLUDE. They could be
initialized by configure; and then I could set FUNCTIONS_EXCLUDE='Commands/*
User/*' FUNCTIONS_INCLUDE='Users/_configure' to get only this one installed?


> * --disable-fndir or --enable-fndir=no turns off both installation of
>   functions and the default $fpath/$FPATH
>

See above.



New Completion Intialisation. Again.

Now, that we (almost) have the stuff there in fpath automagically, please,
consider once again making compinit a function. It would provide for
system-independent rc files - instead of figuring out, where the hell these
functions are placed here, you simply write compinit - and you're done.

I would even opt for a simple builtin that simply sources this file (may be,
under different name to avoid confusion). That file could be then placed in
different dir - let's say, smply ${datadir}/zsh, so, that it won't mess up
in $fpath.

/andrej

Re: Function installation

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> > * --enable-fndir=directory allows you to specify a function installation
> >   directory; default is ${datadir}/zsh-fns, almost certainly
> >   ${prefix}/share/zsh-fns
> 
> Peter, are you so fond of cryptic names? Why not simply {datadir}/zsh or, at
> least, ${datadir}/zsh/functions ? (In hope, that may be some more stuff will
> evtl go into base dir).

Well, yes, actually... but zsh/functions is fine.

> Peter, what about something like this:
> 
> use variables like FUNCTIONS_INCLUDE and/or FUNCTIONS_EXCLUDE. They could be
> initialized by configure; and then I could set FUNCTIONS_EXCLUDE='Commands/*
> User/*' FUNCTIONS_INCLUDE='Users/_configure' to get only this one installed?

FUNCTIONS_INSTALL (as I've called it) was easy to add.  I've made it get
set by default to all the Completion subdirectories, and Zftp/* gets added
if dynamic is turned on, but you can override it in configure or make.

Is FUNCTIONS_EXCLUDE important?  Things get excluded anyway unless they're
in FUNCTIONS_INSTALL, so "make install FUNCTIONS_INSTALL='Core/* Base/*
Builtins/* Users/_configure'" will do what you want.  Excluding probably
means looping over the exclusion variable inside the $FUNCTIONS_INSTALL
loop, which I'd like to avoid.

> Now, that we (almost) have the stuff there in fpath automagically, please,
> consider once again making compinit a function. It would provide for
> system-independent rc files - instead of figuring out, where the hell these
> functions are placed here, you simply write compinit - and you're done.

The stuff only gets put into fpath when you run compinit because it knows
the path to compinit, which it wouldn't if it were a function; you'd have
to give it the -f option.  So the nettle of deciding where the things are
has to be grasped anyway.  But this is all supposed to be handled
seamlessly by running compinstall.  At least with the function installation
stuff, you get a sensible default $fpath, which compinstall will check.

One thing's been niggling at me:  if there's a central function repository,
and the user has their own functions, then compinit.dump has to be somewhere
else, probably not in the same directory as compinit.  It looks like
compinit will need to be a bit smarter about working this out.

-- 
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: Function installation

[Andrej Borsenkow]

>
> The stuff only gets put into fpath when you run compinit because it knows
> the path to compinit, which it wouldn't if it were a function; you'd have
> to give it the -f option.  So the nettle of deciding where the things are
> has to be grasped anyway.  But this is all supposed to be handled
> seamlessly by running compinstall.  At least with the function
> installation
> stuff, you get a sensible default $fpath, which compinstall will check.
>

Is it different attitude, or something I'm hopelessly missing?

I have a feeling, that new completion is still being considered as
experimental by most of zsh-workers. I see it as inherent part of future
zsh. And that is exactly what I want to avoid - running compinstall for
every new user.

What is the point of it anyway? The functions are already there in
system-wide location. Zsh already knows where they are. The path is already
in fpath. Why would I need to run yet another intialisation function?

About the "nettle of deciding" - Zsh *does* know where they are (from
configure). I don't insist on function or builtin - but let's give users a
parameter COMPINIT that holds full pathname of compinit. That would provide
for quite portable rc

[[ -n "$COMPINIT" ]] && $COMPINIT ...

that will automatically cover installation without new completion as well.


> One thing's been niggling at me:  if there's a central function
> repository,
> and the user has their own functions, then compinit.dump has to
> be somewhere
> else, probably not in the same directory as compinit.  It looks like
> compinit will need to be a bit smarter about working this out.
>

As Sven suggested, put it in $HOME by default. But there is more intricate
problem - what, if I'd like to override default functions? Is it enough to
put user-defined directory before system-wide in fpath?

/andrej

Re: Function installation

[Sven Wischnowsky]

Peter Stephenson wrote:

> One thing's been niggling at me:  if there's a central function repository,
> and the user has their own functions, then compinit.dump has to be somewhere
> else, probably not in the same directory as compinit.  It looks like
> compinit will need to be a bit smarter about working this out.

Why not just put it in HOME or the rcs directory and call it .zcomp or 
.zcompdump or something? If the user wants another file he can still
give compinit an argument.

Bye
 Sven


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