Re: [O] [patch] Support CUSTOM_ID property in latex export

[Nicolas Goaziou]

Hello,

Richard Lawrence <address@hidden> 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