Re: Default fpath

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mar 11,  9:29pm, Oliver Kiddle wrote:
} Subject: Default fpath
}
} I'm not convinced that the current situation with respect to zsh setting
} up the fpath to point to all the directories it installs (plus
} site-functions) is the best way of doing it.

I'm also back to the problem that I install into /usr/local/stow/zsh/
and then use the "stow" package to symlink into /usr/local/ -- but the
compiled-in fpath still references /usr/local/stow/zsh/share/zsh.  I'd
fixed this at one point but it seems to have reverted.  (Same for the
module_path.)

} My .zshrc file contains this:
} 
} fpath=( $fpath(N) ~/.zfunc $fpath[1]/* )
} typeset -U fpath
} for dir in ~/.zfunc(N) $fpath[1]/*
}     [[ -d $dir ]] && autoload $dir/[^_]*(.N:t)
} autoload -U allopt zed
} ...
} autoload -U compinit
} compinit -d
} 
[...]
} 
} As a result of $fpath being set to include all the installed function
} directories, I have to add directories to $fpath, then loop through the
} same duplicated list of directories to autoload any functions. I can't
} just loop through all directories in $fpath and autoload everything
} because I don't want all the zsh supplied functions in Misc.

This gives me an idea ... it ought to be possible to point autoload (or
some new builtin) at a zcompiled digest file and have it mark all the
functions therein for autoloading.  That way, you could (once) select
the functions to compile into the digest, then simply add the digest to
your $fpath and issue a single autoload command.  (Note 1)

The digest-file equivalent of `autoload $dir/*(.)`, you see.  I suppose
you can do `autoload ${$(zcompile -t file.zwc):t}` but that requires an
extra process, and it doesn't cover cases where one component file of
the .zwc contained multiple function definitions.

Meanwhile, I use something like this:

	typeset -U fpath zfpath
	zfpath=( ... )			# Personal function dirs here
	autoload $^zfpath/*(N.:t)	# Aliases OK in my own funcs
	(( $#fpath )) && autoload -U compinit
	fpath[(r)*site-func*]=( $zfpath )

It's actually more complicated than that because I'm in the middle of
inventing some code to set zfpath in a $ZSH_VERSION-specific way, so I
can shuffle out some old functions that aren't needed anymore.  I don't
put anything in site-functions, ever; hence re-slicing it with $zfpath.

Hmm, just noticed that if site-functions doesn't appear in $fpath, but
it's otherwise non-empty, that's going to add $zfpath to the end, not
somewhere near the beginning.  Have to think about that; I don't have
any overrides for the default set of functions *now* ...

} I'm not entirely convinced that putting site-functions in the $fpath is
} a good idea. On many installations, it won't exist, some people might
} want to put it elsewhere or call it something else

That's an argument for making the location a configure-time option, at
least, with one option being to leave it out entirely.  What harm does
it do, though, to have a directory in $fpath that contains no files?

} and others like me subdivide it into various subdirectories but don't
} put any functions directly in it.

There's certainly not going to be a compile-time fix for that -- nor a
way to get compinit to deal with it properly AFAICT.  So you're still
going to have to autoload the functions from those directories yourself.

} As a result of $fpath being set to include all the installed function
} directories, I have to add directories to $fpath, then loop through the
} same duplicated list of directories to autoload any functions. I can't
} just loop through all directories in $fpath and autoload everything
} because I don't want all the zsh supplied functions in Misc.

We need to clean up Misc/ anyway; the compctl-related functions should
be called out as such, not lumped in with other utilities, so that they
can be avoided now and more easily obsoleted in the future.

} Many people upgrading from older zsh or learning about $fpath anew
} will assign to $fpath in their .zshrc, clobbering it's current value
} so I think it is better if they are only added by compinit.
                             ^^^^
"They" being the directories that contain completion functions.

I submit that this mistake can't survive very long, because users won't
be able to run compinit if they've removed its directory from $fpath.
It's the sort of mistake you make exactly once.

} Similarly, promptinit would add the Prompts directory to $fpath.

But then you're enforcing --enable-function-subdirs behavior, aren't you?

Further, if compinit added directories to $fpath, how does the user
specify in what order those directories are added?  I might not want my
local directories to come before the zsh system ones; e.g. with 3.0.x,
I only want my local copy of `multicomp' found when the one that came
with zsh isn't installed, because mine's rather old and the chances are
that the system one works better.  (Yes, I should just copy a newer one
into my directory.  That's not the point.)

} The obvious solution is to have a variable which is set when zsh first
} runs such as $ZSH_FUNCTIONS. In fact, it might be better in the longer
} term to have an associative array which points to any compile-time
} defined directories. So we would have something like:
} ZSH_INSTALL[functions]=/usr/local/share/zsh/$ZSH_VERSION/functions
} ZSH_INSTALL[lib]=/usr/local/lib/zsh/3.1.6-dev-19
} ZSH_INSTALL[share]=/usr/local/share/zsh
} etc.

That's a reasonable idea, though (other than "functions" and maybe "lib")
I can't decide what the standard set of key names should be.  I dislike
the idea of following the autoconf naming convention; I don't really
think bindir, datadir, infodir, etc. are especially useful.

Backing up again:
 
} The other thing which I've never understood is why compinit (and
} promptinit) is an autoloaded function: nobody would ever want to run it
} more than once in a session so why isn't it just sourced?

It's a function so that it can use setopt localoptions, create local
variables, and use "autoload -U" to avoid alias expansions.  That last
is probably the most important.

There's a lengthy discussion of this from June 1999 in the archives; most
messages in the thread have the subject
	Re: PATCH: Re: Completion and global aliases
and the patch that resulted is article 6857.

Of course, we could add a "source -U ..." or some such to stop aliasing
even in sourced files, but as source has never accepted options before I
find that slightly distasteful.


Note 1 -- While we're on the topic of zcompile, it could use:
(1) a way to append to an existing .zwc, rather like `ar' works, and
(2) an option to say whether each function should be autoloaded zsh-style
    or ksh-style, so that the right thing happens regardless of the run-
    time setting of kshautoload.)

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