From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [patch] Support CUSTOM_ID property in latex export Date: Tue, 18 Feb 2014 22:56:16 +0100 Message-ID: <87lhx82igv.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> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFsdz-0000ZR-HN for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 16:56:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFsdu-00017N-KE for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 16:55:59 -0500 Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:41843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFsdu-00017H-9h for emacs-orgmode@gnu.org; Tue, 18 Feb 2014 16:55:54 -0500 Received: by mail-we0-f179.google.com with SMTP id q58so11877103wes.24 for ; Tue, 18 Feb 2014 13:55:53 -0800 (PST) In-Reply-To: <871tz24y4q.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> (Richard Lawrence's message of "Sun, 16 Feb 2014 12:10:29 -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 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. > 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? >>> 2) I hope this doesn't happen, but there may come a time when I need to >>> move away from Org and just use straight LaTeX. Having control over the >>> labeling will make this transition much easier, because it means I won't >>> have to worry about manually changing the labels in a long document from >>> Org's default "sec-..." numbering to my own semantic labels. Here, I understand the problem. There is a solution, but it is not trivial. You can write a parse-tree filter that collects associations between custom ID (obtained with `org-element-property') and headline numbers (obtained with `org-export-get-headline-number'). You can store this alist in the info channel. Then, you write a link and headline filter that replaces "sec-..." labels and refs with their custom ID equivalent. > Maybe so, but that's actually sort of my point. At the moment, my > options are: > 1) Use multiple labeling schemes, one accessible to Org, one > accessible to LaTeX, and use the former in Org text and the latter > in embedded LaTeX > 2) Avoid using Org's labeling/linking entirely, and just explicitly specify > all my \labels and \refs > 3) Rely on my understanding of how Org will produce section labels > when I \ref sections inside embedded LaTeX blocks > > Option 1 creates ambiguity, is fragile, and is thus not ideal. "Not ideal" is not necessarily "wrong". Also, as explained above, your patch is not ideal either. I just think the current implementation is (slightly) better. Now, if you can improve your suggestion and solve my concerns about it, I'm still all ears. > Having Org pass CUSTOM_ID through to \label does in a sense mean the > user is relying on an implementation detail of the exporter, but in an > explicit and predictable way, which makes it unproblematic. Consider an > analogy: users who specify :options in an #+ATTR_LATEX declaration are > also relying on the implementation details of the exporter (they are > assuming it will export their options text unchanged), but this is not > problematic because they are explicitly requesting that the default > behavior (don't use options, or use some default options) be overridden. > Isn't overriding labeling with CUSTOM_ID pretty much the same thing? No it isn't. Exporting :options value unchanged is part of its specifications. It is even written in the manual. CUSTOM_ID specifications require an export back-end to provide a way to link to a headline with some specific syntax. We happen to disagree on how this should be done. This is an implementation detail. Regards, -- Nicolas Goaziou