From: tftorrey@tftorrey.com (T.F. Torrey)
To: Aaron Ecay <aaronecay@gmail.com>
Cc: emacs-orgmode@gnu.org, rasmus@gmx.us
Subject: Re: Bug: HTML export ignoring CUSTOM_ID properties
Date: Sat, 18 Apr 2015 20:40:03 -0700 [thread overview]
Message-ID: <87sibw23cc.fsf@jack.tftorrey.com> (raw)
In-Reply-To: <87zj65jczm.fsf@gmail.com> (message from Aaron Ecay on Sat, 18 Apr 2015 23:38:28 +0100)
Hello Aaron,
Aaron Ecay <aaronecay@gmail.com> writes:
> You wrote:
>
>> Links may work from inside Org, but the original intent of CUSTOM_ID was
>> to produce a stable ID for the HTML export that could be linked to from
>> outside Org.
>
> I think this is true. Looking at the pages in Worg, for example,
> provides ample evidence of this strategy in action.
If this functionality were not provided by CUSTOM_ID, we would need to
invent a different property to serve the function.
> CUSTOM_ID is also sometimes needed for latex export
> (cf. org-latex-prefer-user-labels). It is important for IDs to be
> unique, and to conform to certain format restrictions. What if
> CUSTOM_ID properties were checked for these requirements when exporting,
> raising an error if they are not suitable and otherwise passing through
> to the export output? This would maintain CUSTOM_ID as an interface to
> labeling systems outside org (latex \ref{}, html #anchor links, ...),
> but would also make export more robust. It’s also in line with recent
> changes to raise export errors for undefined macros, unresolvable links,
> etc.
This is what I suggested in an earlier e-mail (which was unreasonably
cordial, yet summarily dismissed in a way that made me angry, and which
was sent in response to the summary dismissal of my polite bug report).
Does it warrant an error, though? I've been using the functionality
extensively for years, and I can remember only one time that I had an
inadvertent problem caused by a duplicate CUSTOM_ID. A simple warning
would have headed that off.
On the contrary, if the show is going to
stop with an error, I will have to make sure my documents meet someone
else's idea of what is useful. For instance, many of my documents get
exported together (web pages with #news sections, for instance), and it
would be unnecessarily inconvenient making the CUSTOM_ID unique across
all agenda files. Someone else, however, might want that.
I'm wondering why this is being addressed at all. Is this actually a
problem for someone? Or is this just another attempt to save
hypothetical users' feet? Or is it just a side-effect of other
refactoring?
Best,
Terry
--
T.F. Torrey
next prev parent reply other threads:[~2015-04-19 4:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 23:19 Bug: HTML export ignoring CUSTOM_ID properties T.F. Torrey
2015-04-17 0:20 ` Rasmus
2015-04-17 18:20 ` T.F. Torrey
2015-04-18 13:57 ` Rasmus
2015-04-18 18:26 ` T.F. Torrey
2015-04-18 22:38 ` Aaron Ecay
2015-04-19 3:40 ` T.F. Torrey [this message]
2015-04-18 23:08 ` Nicolas Goaziou
2015-04-19 4:20 ` T.F. Torrey
2015-04-19 9:08 ` Nicolas Goaziou
2015-04-19 21:11 ` T.F. Torrey
2015-04-19 14:47 ` Rasmus
2015-04-21 5:37 ` Daniel Clemente
2015-04-21 7:25 ` Nicolas Goaziou
2015-04-23 18:15 ` Daniel Clemente
2015-04-23 19:21 ` Nicolas Goaziou
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=87sibw23cc.fsf@jack.tftorrey.com \
--to=tftorrey@tftorrey.com \
--cc=aaronecay@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=rasmus@gmx.us \
/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).