Re: fndir introspection, site-packages documentation

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

This really doesn't belong on zsh-users any more, in fact it probaby should
have started out on zsh-workers to begin with.  I haven't changed the list
target yet for this reply, but I suggest follow-ups go there.

Aside:  I don't suppose there's any point in again begging people to stop
attaching patches as "text/x-patch" or "text/x-diff" or other silly MIME
types that half my email clients say there is no app for, and the other
half pass to some miscelleneous (wrong) app because of the ".patch" file
extension, which someone seems to think has something to do with setting
up network tunnels.

Grumble.  Text bleeping plain, or just put them in the message body.

I suppose I should also rant about email client authors who don't have
a "text/*" fallback.  Rant rant.  We now return you to your regularly
scheduled curmudgeonry.

On Mar 15,  3:14am, Roman Neuhauser wrote:
}
} uh, sorry, i meant "sitefndir".  anyway, how about the attached patch?

Indeed, I should have gotten that from your example instead of answering
the literal question.

}   ./Src/zsh -fc 'print -l "$ZSH_SITEFNDIR"'     
}   /omg/share/zsh/site-functions

I don't have any strong objection to this although it seems like putting
this value into every shell is overkill for the specialized purpose to
which you propose to use it.  Can anyone give me a situation in which an
oridinary user (i.e., not a software packager) would need this?

If there *is* such a situation, then the parameter name should be a lot
less configure-script-ified, "SITEFNDIR" is rather meaningless in any
other context.

Your doc change mentions

+tt(/usr/local/share/zsh/site-functions) is always included,
+even if it does not exist, and cannot be configured away.

That's not quite correct: --disable-site-fndir turns it off, leaving
only $prefix/share/zsh/$ZSH_VERSION/functions (or subdirs).

Also it's bad form in the doc to use references like var(prefix) when
you haven't mentioned where the value of prefix comes from, which in
turn requires delving into discussion of build configuration, which
is out of scope for end-user doc, which is another reason we haven't
included these details before.

(There are some parts of the doc where we try to actually pull in the
configuration values and embed them, so that we don't have to make
references to configure variables, but that gets ugly.)

Maybe the right thing is to throw all of this into a module (and doc
for that module) that can be loaded by package maintainers to provide
access to zsh's configure settings, but which other users can ignore.
The more I think about it the more I like that idea.