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
   :CUSTOM_ID: foo
   :LATEX_LABEL: bar
Some text ... this is section [[#foo]].

would become:

\subsection{A headline}
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.


(If possible, please encrypt your reply to me using my PGP key:
Key ID: CF6FA646
Fingerprint: 9969 43E1 CF6F A646.
See for more information.)

Reply via email to