From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8632 invoked by alias); 15 Mar 2015 19:14:56 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 20015 Received: (qmail 23871 invoked from network); 15 Mar 2015 19:14:55 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=4TOfDKcpqTlw7W2hFjbD0LOkLx9AlTqLnupbnOQAhf0=; b=h/y+zKj0th9USncDWYSXp52AY1XqbKOWMcR6tqdH42IQFk3wyLgdMX4pPPyJQBvdJs wJ3clU2LvAZLoZMK/tLHVFVhNQBT0HAyEWXQ2npQGQKedLxsL72tBg+lbH9d4ine9Io3 lX1IBCZ9RyILxMbA02eb9YwNEcNgnkA385ETNNzt5yOZZwYqSfBbuOWuRYocx0pFe5iY nu32G4NZCCs6v8ou/KuVZiohYkG+6PWTIRhSxISij3IWscurHLupNclhujeiVHwsc++D PnLunIt5B7758TXMtSiaJCO7Z1mnZb7zqqe3aQGuUWfxeTpOhLtmD8n3yz4v06kHcLD8 XAmA== X-Gm-Message-State: ALoCoQna509lt4CAyYot73KXlQEFwdmgpS9/XZAwSfIzlcePcC7S71NYwn6OcXCYXxqqDjmlqv+t X-Received: by 10.182.24.202 with SMTP id w10mr45821996obf.9.1426446890805; Sun, 15 Mar 2015 12:14:50 -0700 (PDT) From: Bart Schaefer Message-Id: <150315121447.ZM27996@torch.brasslantern.com> Date: Sun, 15 Mar 2015 12:14:47 -0700 In-Reply-To: <20150315021436.GQ4524@isis.sigpipe.cz> Comments: In reply to Roman Neuhauser "Re: fndir introspection, site-packages documentation" (Mar 15, 3:14am) References: <20150313224121.GO4524@isis.sigpipe.cz> <150313203904.ZM25016@torch.brasslantern.com> <20150315021436.GQ4524@isis.sigpipe.cz> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: fndir introspection, site-packages documentation MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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.