Re: Moving completion functions

[Oliver Kiddle <opk@u.genie.co.uk>]

Bart wrote:

> Long, long ago it was decided that it was a bad idea to import FPATH.
> So long ago that it's not in the zsh-workers archive, unfortunately.
> Probably has something to do with the fact that its a huge security
> hole, i.e., you can cause some other user's shell to inherit a trojan
> via any function you can guess he might autoload.

That's a good point. I have a horrible feeling you mentioned that before
sometime. It made me wonder though: surely PATH is similar. I've always
tended to add to the path in my .zshrc so this makes me wonder if it
wise to set it fully and in .zshenv for similar security reasons.
 
> } As I said with the original suggestion, there could be a variable set
> } to point to the base of the installed functions.
> 
> A parameter set how?  By hardwiring it at compile time?  I suppose that
> the zsh/complete module could define one.

Yes, or in the same way as how $fpath is set. I've used things like
${fpath[(r)*Core]:-$fpath[(r)*/functions]} in a few places (such as my
zrecompile script) to get at this directory so it might be useful
anyway.

I did a bit of thinking last week and as for the whole suggestion about
setting $fpath, I think you've convinced me that the current situation
is probably just as good/bad as my suggestion. I think it would
definitely be worse if we ended up supporting both ways of doing it with
a configure option so I won't mention it again. So I suggest we leave it
as it is and I shut up.

> } Do we need to account for kshautoload though?

> The only way is to "zcompile -z" the whole thing and then put the .zwc
> file in fpath.  This has been mentioned before (it may even be in the
> docs somewhere).

I couldn't see it in the docs but these things aren't so easy to find.
If it gets asked much, we can always add it to the FAQ.

As for sourcing compinit, I suppose it might have a performance
implication. I just felt that sourcing is more natural for what it is
doing and is possibly an easier concept for new users to understand.
>From the perspective of my own use of zsh, I don't really care how
compinit does its stuff. I'm not too keen on us complicating compinit so
that sourcing it is an option but with autoload being the method
mentioned in the manual.

Bart Schaefer wrote:
> 
> I would include harden, checkmail, mere, and definitely zed as "useful
> functions which many people might want to use," but proto is marginal
> (how many people code in C with exactly Paul Falstad's style?) and to
> autoload all those those trivial one-liners is IMO a waste.

Sorry, I didn't really know what proto was but assumed it was something
more general and so more useful.

> It's too big to reasonably put in compctl-examples and remains relevant

fair enough. Again I've never used it and just glanced to see what it
did.

> > > Functions/Misc/run-help             Functions/Misc  # Add #autoload line?
> >
> That's why there's a `?' at the end of my comment.  So, leave run-help
> as it is.

Er? I saw the ? and meant my comment as an answer but probably got the
tone of it wrong.

In some ways, I wonder that #autoload as a wider feature might be
useful.

> I'd actually rather split compctl-examples up into smaller files and put
> them all in Functions/Compctl, but I suppose we're trying to discourage
> use of compctl ...

That's not a bad idea. They'd be out of the way in the Compctl directory
so I don't think it would be too much of an encouragement. More
functions in Compctl would better justify its existence. I've also been
convinced that compctl still serves a purpose.

> The main thing I want to do with the example startup files is to add a
> batch of comments, possibly in all-caps, telling system administrators
> NOT to drop these files into /etc/z*.  And maybe even put a "return 0"
> at the top of each file just in case some nimrod copies them to /etc/
> without looking at them.

I would definitely agree with that.

Oliver