From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Richard Lawrence <richard.lawrence@berkeley.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: [patch] Support CUSTOM_ID property in latex export
Date: Tue, 18 Feb 2014 22:56:16 +0100 [thread overview]
Message-ID: <87lhx82igv.fsf@gmail.com> (raw)
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")
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.
> 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
next prev parent reply other threads:[~2014-02-18 21:56 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 [this message]
2014-02-18 22:35 ` Richard Lawrence
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=87lhx82igv.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=richard.lawrence@berkeley.edu \
/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).