From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [patch] Support CUSTOM_ID property in latex export
Date: Tue, 18 Feb 2014 14:35:00 -0800 [thread overview]
Message-ID: <87mwho9hij.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <87lhx82igv.fsf@gmail.com>
Nicolas Goaziou <n.goaziou@gmail.com> writes:
> Hello,
>
> Richard Lawrence <richard.lawrence@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.
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.)
next prev parent reply other threads:[~2014-02-18 22:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 20:19 [patch] Support CUSTOM_ID property in latex export Richard Lawrence
2014-02-15 22:44 ` Nicolas Goaziou
2014-02-15 23:43 ` Richard Lawrence
2014-02-16 9:10 ` Nicolas Goaziou
2014-02-16 20:10 ` Richard Lawrence
2014-02-18 21:56 ` Nicolas Goaziou
2014-02-18 22:35 ` Richard Lawrence [this message]
2014-02-19 12:43 ` Nicolas Goaziou
2014-02-20 5:04 ` Richard Lawrence
2014-02-21 19:35 ` Richard Lawrence
2014-02-22 9:24 ` Nicolas Goaziou
2014-02-22 20:35 ` Richard Lawrence
2014-02-22 22:31 ` Nicolas Goaziou
2014-02-23 0:37 ` Richard Lawrence
2014-02-23 8:37 ` Nicolas Goaziou
2014-02-23 8:53 ` Achim Gratz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mwho9hij.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me \
--to=richard.lawrence@berkeley.edu \
--cc=emacs-orgmode@gnu.org \
--cc=n.goaziou@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).