From mboxrd@z Thu Jan 1 00:00:00 1970 From: tftorrey@tftorrey.com (T.F. Torrey) Subject: Re: Bug: HTML export ignoring CUSTOM_ID properties Date: Sat, 18 Apr 2015 20:40:03 -0700 Message-ID: <87sibw23cc.fsf@jack.tftorrey.com> References: <87zj65jczm.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39298) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjgig-0007Qd-A5 for emacs-orgmode@gnu.org; Sun, 19 Apr 2015 00:20:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yjgid-0003q7-4j for emacs-orgmode@gnu.org; Sun, 19 Apr 2015 00:20:34 -0400 Received: from relay6-d.mail.gandi.net ([2001:4b98:c:538::198]:52776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjgic-0003pv-VD for emacs-orgmode@gnu.org; Sun, 19 Apr 2015 00:20:31 -0400 In-Reply-To: <87zj65jczm.fsf@gmail.com> (message from Aaron Ecay on Sat, 18 Apr 2015 23:38:28 +0100) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Aaron Ecay Cc: emacs-orgmode@gnu.org, rasmus@gmx.us Hello Aaron, Aaron Ecay 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=E2=80=99s also in line with r= ecent > 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 --=20 T.F. Torrey