Re: Bug: HTML export ignoring CUSTOM_ID properties

[tftorrey@tftorrey.com (T.F. Torrey)]

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