From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: Re: Custom entry IDs in HTML export Date: Thu, 16 Apr 2009 08:55:26 +0200 Message-ID: <1FEE16B4-2913-487C-8822-094FF4EC725C@gmail.com> References: <87myb7w2s9.fsf@CPU107.opentrends.net> <6BF0FCBC-4343-4B8C-9A16-F4B9AC9B0F48@gmail.com> <87eiwiluft.fsf@gollum.intra.norang.ca> <87y6uqwsjw.fsf@kassiopeya.MSHEIMNETZ> <871vsfjkm3.fsf@CPU107.opentrends.net> Mime-Version: 1.0 (Apple Message framework v930.3) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LuMob-0008TI-OY for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 04:19:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LuMoW-0008R7-Qo for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 04:19:21 -0400 Received: from [199.232.76.173] (port=60703 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LuMoW-0008R0-KF for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 04:19:16 -0400 Received: from ey-out-1920.google.com ([74.125.78.146]:65290) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LuMoW-0000XF-5D for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 04:19:16 -0400 Received: by ey-out-1920.google.com with SMTP id 13so49883eye.24 for ; Thu, 16 Apr 2009 01:19:14 -0700 (PDT) In-Reply-To: <871vsfjkm3.fsf@CPU107.opentrends.net> 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: Daniel Clemente Cc: Bernt Hansen , org-mode mailing list Hi Sebastian, I kind of like the idea to have a property that can be used to set an ID, as an alternative to the <> notation. Actually, using a property seems a lot cleaner, thanks for coming up with this idea, Daniel. I can also follow the reasoning that it is useful to have the table of contents link to the human-readable id, because it provides a general, simple workflow to retrieve a link that will persist through changes of the document. This workflow was described also by Bernt earlier in this thread. Finally, I also agree that the main id in the

tag should be the automatically generated one because this is best for automatic processing and because of all the arguments you have presented. Would it cause problems for org-info.js if the toc points to a user specified anchor in the headline, instead of the main ID that is inside the

tag? THis would really be the only required change. - Carsten On Mar 30, 2009, at 1:49 PM, Daniel Clemente wrote: > El dv, mar 27 2009, Sebastian Rose va escriure: >> >> What we have now, just as Carstens said: >> >> # <> >> * Section B >> >> Creates this headline in HTML: >> >>

2 =20 >> Section B

>> >> This is enough for all the use cases I can think of. >> > > Yes, this is enough except for two things: > 1. The TOC still links to #sec-2 and the user can't change that > 2. Your syntax doesn't fold very well in the outliner. I mean: if =20 > you use > >> # <> >> * Section B > > then the comment appears at the end of the previous section, and =20 > you can miss it when you are viewing the heading =84Section B=93. I =20= > would swap both lines (solution 1): > >> * Section B >> # <> > > But since there are already LOGBOOK drawers under the heading, it =20 > would be a lot clearer to use a property, like EXPORT_ID (solution 2): > >> * Section B >> :PROPERTIES: >> :EXPORT_ID: human-readable >> :END: > > > In this way, the TOC can reliably find the EXPORT_ID, and then =20 > generate: >>

2 =20 >> Section B

> > (You could also leave *just* the human-readable id, but having two =20= > is not bad. > > > I would prefer solution 1, but I don't because I'm not sure that =20 > the TOC can find the ID if it is written as a comment anywhere under =20= > the heading (and together with other things). > > Solution 2 involves thus: a new property to specify the human-=20 > readable entry ID, which will be used to link to the entry. The =20 > automatic ID (#sec-2) will still work for all entrys. > > >> >> * 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 =20 >> 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 =20= >> way >> to detect the human readable one. There will be no way to _know_ =20 >> that >> the 's ID is the prefered one used for human readable links. >> > > Solution 2 doesn't break the parsing techniques you use; in fact it =20= > can also make clearer which ID is the human readable one and which =20 > one not. > > > This is not extremely important; just useful: > - for pages with many incoming links from external sites > - to ensure link integrity (now you can't assure that links will =20 > still work in 1 year ... or in some weeks) > - to avoid that HTML visitors get directed to a wrong section and =20 > can't find what they searched > > > Greetings, > Daniel > > > _______________________________________________ > Emacs-orgmode mailing list > Remember: use `Reply All' to send replies to the list. > Emacs-orgmode@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-orgmode