Hello, Richard Lawrence <richard.lawre...@berkeley.edu> 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
