[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orgmode] Re: Custom entry IDs in HTML export
From: |
Sebastian Rose |
Subject: |
Re: [Orgmode] Re: Custom entry IDs in HTML export |
Date: |
Thu, 16 Apr 2009 10:50:26 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux) |
Carsten Dominik <address@hidden> 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 <<target>>
> 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 <h3> 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 <h3> 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 that
change. The script should not rule the HTML export and it will be an
easy thing to do.
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:
>>>
>>> # <<human-readable>>
>>> * Section B
>>>
>>> Creates this headline in HTML:
>>>
>>> <h2 id="sec-2"><a name="human-readable" id="human-readable"></a>2 Section B
>>> </h2>
>>>
>>> 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 you use
>>
>>> # <<human-readable>>
>>> * Section B
>>
>> then the comment appears at the end of the previous section, and you can
>> miss
>> it when you are viewing the heading „Section B“. I would swap both lines
>> (solution 1):
>>
>>> * Section B
>>> # <<human-readable>>
>>
>> But since there are already LOGBOOK drawers under the heading, it 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 generate:
>>> <h2 id="sec-2"><a name="human-readable" id="human-readable"></a>2 Section B
>>> </h2>
>>
>> (You could also leave *just* the human-readable id, but having two is not
>> bad.
>>
>>
>> I would prefer solution 1, but I don't because I'm not sure that the TOC can
>> find the ID if it is written as a comment anywhere under the 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 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 <a> 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 <h3>'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 <a>'s ID is the prefered one used for human readable links.
>>>
>>
>> Solution 2 doesn't break the parsing techniques you use; in fact 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 still work
>> in
>> 1 year ... or in some weeks)
>> - to avoid that HTML visitors get directed to a wrong section and can't find
>> what they searched
>>
>>
>> Greetings,
>> Daniel
>>
>>
>> _______________________________________________
>> Emacs-orgmode mailing list
>> Remember: use `Reply All' to send replies to the list.
>> address@hidden
>> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>
--
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
Email: address@hidden, address@hidden
Http: www.emma-stil.de
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Carsten Dominik, 2009/04/16
- Re: [Orgmode] Re: Custom entry IDs in HTML export,
Sebastian Rose <=
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Carsten Dominik, 2009/04/16
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Sebastian Rose, 2009/04/16
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Carsten Dominik, 2009/04/16
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Sebastian Rose, 2009/04/16
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Carsten Dominik, 2009/04/16
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Sebastian Rose, 2009/04/16
- Re: [Orgmode] Re: Custom entry IDs in HTML export, Carsten Dominik, 2009/04/17