From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [patch] Support CUSTOM_ID property in latex export Date: Sat, 22 Feb 2014 23:31:02 +0100 Message-ID: <87k3cmye3d.fsf@gmail.com> References: <87y51cgmc5.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> <87mwhsro6c.fsf@gmail.com> <87vbwggcwb.fsf@berkeley.edu> <87iosfs9sb.fsf@gmail.com> <871tz24y4q.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> <87lhx82igv.fsf@gmail.com> <87mwho9hij.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> <87d2ij2ryp.fsf@gmail.com> <87ob20gsxv.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> <878ut31ov6.fsf@gmail.com> <87a9di7unn.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHL5p-0001xQ-Gw for emacs-orgmode@gnu.org; Sat, 22 Feb 2014 17:30:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WHL5k-0004mZ-KH for emacs-orgmode@gnu.org; Sat, 22 Feb 2014 17:30:45 -0500 Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:42503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WHL5k-0004mV-CX for emacs-orgmode@gnu.org; Sat, 22 Feb 2014 17:30:40 -0500 Received: by mail-wi0-f171.google.com with SMTP id cc10so1911017wib.10 for ; Sat, 22 Feb 2014 14:30:39 -0800 (PST) In-Reply-To: <87a9di7unn.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> (Richard Lawrence's message of "Sat, 22 Feb 2014 12:35:24 -0800") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Richard Lawrence Cc: emacs-orgmode@gnu.org Richard Lawrence writes: > True, it is explained that CUSTOM_ID must be unique, but not that the > generated label must be. I have changed this to: > > "You are responsible for ensuring that the value is a valid LaTeX > \\label key, and that no other \\label commands with the same key appear > elsewhere in your document." > > That seems clearer to me; it forbids e.g. introducing labels with the > same key on a #+LATEX: line. Sound good? Fair enough. > I can't actually find a clear explanation anywhere of exactly what is > and isn't allowed in a label key. All the LaTeX documentation seems to > just say: > > "A key can consist of any sequence of letters, digits, or punctuation > characters. Upper and lowercase letters are different." > > But clearly, the issue is what sort of "punctuation" is allowed. ":" > and "_" are OK, but "%" and "$" aren't...is there a definitive list > somewhere I should refer to? I don't know any. > Maybe I should just say the user should have a look at the regexp in > org-export-solidify-link-text? Besides alphanumeric characters, this function allows "_", ".", "-" and ":". I think it is safe to assume only these punctuation characters are allowed. Also, the docstring should insist on the fact that this limitation only applies when the variable is non-nil. >> There is one thing to consider here. We can define the new variable as >> a back-end options, i.e., add >> >> (:latex-manual-id nil nil org-latex-custom-id-as-label) >> >> >> in the back-end definition (the name of the property doesn't matter >> much, you can change it). > >> >> This is not strictly necessary, but it allows, for example, to change >> its value for specific projects (in the publishing sense) without >> setting the variable globally. >> >> If you think it is useful to do so, >> >> (and org-latex-custom-id-as-label >> >> should become >> >> (and (plist-get info :latex-manual-id) >> >>> + (let* ((custom-label (and org-latex-custom-id-as-label >>> + (org-element-property :CUSTOM_ID destination))) >> >> Ditto. >> > > OK, that sounds like a good idea, but are these the only changes that > would be necessary? Yes. > Where should the name of the back-end option and its relationship to > this variable be documented? Probably in: (info "(org) Publishing options") Unfortunately, only generic and html-specific options are described there. We could add a LaTeX section (but it wouldn't contain much). Regards, -- Nicolas Goaziou