From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Rose Subject: Re: Re: Custom entry IDs in HTML export Date: Fri, 27 Mar 2009 22:32:58 +0100 Message-ID: <87y6uqwsjw.fsf@kassiopeya.MSHEIMNETZ> References: <87myb7w2s9.fsf@CPU107.opentrends.net> <6BF0FCBC-4343-4B8C-9A16-F4B9AC9B0F48@gmail.com> <87eiwiluft.fsf@gollum.intra.norang.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LnJmZ-0003ha-Dp for emacs-orgmode@gnu.org; Fri, 27 Mar 2009 17:40:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LnJmW-0003h5-2y for emacs-orgmode@gnu.org; Fri, 27 Mar 2009 17:40:07 -0400 Received: from [199.232.76.173] (port=55553 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LnJmV-0003h2-Qy for emacs-orgmode@gnu.org; Fri, 27 Mar 2009 17:40:03 -0400 Received: from mail.gmx.net ([213.165.64.20]:37062) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LnJmV-0004WJ-9F for emacs-orgmode@gnu.org; Fri, 27 Mar 2009 17:40:03 -0400 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bernt Hansen Cc: org-mode mailing list I don't think this is an important change. Here some thoughts that come to mind in this context. What we have now, just as Carstens said: # <> * Section B Creates this headline in HTML:

2 Section B

This is enough for all the use cases I can think of. The section and headline may be detected through the anchor by any DOM parser. Also, creating Org-files from Database entries or similar is simple (Php): fputs($fh, ' # <> * ' . $row['headline']); If a change should be done, how will that change look like? * Distinguishing automatic and human readable IDs One thing I like is, that we now _can_ distinguish the `human-readable-target' (human readable) from the `sec-2' (not human readable and not context related) using a regular expression. In org-info.js, I can now prefere the human readable ID in from an automatic created one, and thus use that to create the links for `l' and `L'. The same holds true for other programming languages and parsers. If we open the

's ID for user defined values (bad), we can not distinguish those ID's using a regular expression and there is no way to detect the human readable one. There will be no way to _know_ that the 's ID is the prefered one used for human readable links. If such a change should be done, I'd always prefer the (eventually existing) anchors ID for creating links. Conventions are not a bad thing in general, but they can lead to lot's of `if you... else if... else...' in code and docs. * Quality assurance The automatic IDs in the headline elements, and only those ID's, guaranty the functionality of export and cross referencing in an idiot proof way, which is what I prefer. Regards, Sebastian -- Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 Hannover Tel.: +49 (0)511 - 36 58 472 Fax: +49 (0)1805 - 233633 - 11044 mobil: +49 (0)173 - 83 93 417 Http: www.emma-stil.de