From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Lawrence Subject: Re: [patch] Support CUSTOM_ID property in latex export Date: Tue, 18 Feb 2014 14:35:00 -0800 Message-ID: <87mwho9hij.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44102) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFtHZ-0005gG-8N for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 17:36:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFtHS-0006U1-1h for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 17:36:53 -0500 Received: from mail-pb0-f45.google.com ([209.85.160.45]:40662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFtHR-0006Th-Om for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 17:36:45 -0500 Received: by mail-pb0-f45.google.com with SMTP id un15so17313263pbc.18 for ; Tue, 18 Feb 2014 14:36:44 -0800 (PST) In-Reply-To: <87lhx82igv.fsf@gmail.com> 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Hello, > > Richard Lawrence writes: > >> It seems to me that if you explicitly specify CUSTOM_ID with the intent >> of overriding Org's default labeling, you ought to have some idea what >> can go in a \label, and be prepared to debug your LaTeX compilation if >> there's an error. If you're not prepared to do that, you should limit >> yourself to the default behavior. But if you *are* prepared to do that, >> why should Org prevent you? > > This is the problem. At the moment, CUSTOM_ID has no limitation about > the characters it can use. As long as the value is unique, Org will > create a valid label for it. > > OTOH, you patch introduces a limitation and could force users to debug > LaTeX compilation, even if they didn't want to mess with Org's default > labeling in the first place. If you are *not* prepared, why Org should > force you? > > So, this is not a net benefit in the general case. OK, I can understand this. There are people who are using CUSTOM_ID already, and they shouldn't have to worry about debugging LaTeX if they weren't counting on it. (In my case, I'm not using this property for anything else, so this wasn't an issue, and using CUSTOM_ID provided a handy way to use the [[#link]] syntax to introduce \refs with the label I intended.) Would using a different property---say, LATEX_LABEL---resolve your concerns? This property could be explicitly documented as overriding Org's default labeling, with the value passed down directly to LaTeX. During link resolution, a headline would export with a "\label{VAL}", and a link to a headline with this property would export to "\ref{VAL}", where "VAL" is the value of this property. Thus, e.g., ** A headline :PROPERTIES: :CUSTOM_ID: foo :LATEX_LABEL: bar :END: Some text ... this is section [[#foo]]. would become: \subsection{A headline} \label{bar} Some text \ldots this is section \ref{bar}. That would meet all my needs, I think. In my case it would also be handy to have some way to link to headlines based on the LATEX_LABEL property directly (say, like [[label:bar]]). But that's easy enough to add. >> The strategy you suggest would result in multiple labels in the same >> location in the exported document. This is bad because it introduces >> ambiguity and is thus fragile. The exported document could have two sets >> of \refs which point to two different \labels. Initially, LaTeX >> would compile them to the same thing, but if one of the labels got moved >> or deleted, one set of refs would break. > > Sorry for being dense, but I fail to see where is the "ambiguity". Org > will not get confused with its own internal labels, neither will you > with yours. Do you have a real worrisome situation in mind? The worrisome situation I have in mind is if I find that I eventually need to move away from Org to straight LaTeX. I would want to start with an Org export to LaTeX, and then continue from that point by editing the exported .tex file. In that case, one label could eventually get deleted, or they could drift apart, and then one set of \refs could subtly break (say, if I put a new \subsection in between them). To avoid this, I want the exported .tex file to just use one set of labels. Best, Richard (If possible, please encrypt your reply to me using my PGP key: Key ID: CF6FA646 Fingerprint: 9969 43E1 CF6F A646. See http://www.ocf.berkeley.edu/~rwl/encryption.html for more information.)