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 13:28:52 +0200 Message-ID: <43758593-D9D0-43BC-B4D9-14E036C66271@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> <1FEE16B4-2913-487C-8822-094FF4EC725C@gmail.com> <878wm1ugml.fsf@kassiopeya.MSHEIMNETZ> 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 1LuPmA-0008EZ-UM for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 07:29:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LuPm5-0008DJ-2c for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 07:29:01 -0400 Received: from [199.232.76.173] (port=58968 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LuPm4-0008DG-Uc for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 07:28:56 -0400 Received: from mail-ew0-f160.google.com ([209.85.219.160]:55350) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LuPm4-0007rl-2H for emacs-orgmode@gnu.org; Thu, 16 Apr 2009 07:28:56 -0400 Received: by ewy4 with SMTP id 4so324256ewy.42 for ; Thu, 16 Apr 2009 04:28:54 -0700 (PDT) In-Reply-To: <878wm1ugml.fsf@kassiopeya.MSHEIMNETZ> 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: Sebastian Rose Cc: org-mode mailing list , Bernt Hansen On Apr 16, 2009, at 10:50 AM, Sebastian Rose wrote: > Carsten Dominik writes: >> 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. > > > I'll have to test this before I can give a final answer to this > question. > > But regardless of the results, I will adjust the script to reflect =20 > that > change. The script should not rule the HTML export and it will be an > easy thing to do. But I do want to hear any counter arguments you might have.... - Carsten > > Sebastian > > > >> - 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 would swap =20= >>> 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 the =20 >>> heading (and >>> together with other things). >>> >>> Solution 2 involves thus: a new property to specify the human- >>> 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 =20 >>>> 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 =20= >>>> `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 =20 >>> it can also >>> make clearer which ID is the human readable one and which 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 >> > > --=20 > Sebastian Rose, EMMA STIL - mediendesign, Niemeyerstr.6, 30449 =20 > Hannover > Tel.: +49 (0)511 - 36 58 472 > Fax: +49 (0)1805 - 233633 - 11044 > mobil: +49 (0)173 - 83 93 417 > Email: s.rose@emma-stil.de, sebastian_rose@gmx.de > Http: www.emma-stil.de