From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: Daniel Clemente <n142857@gmail.com>
Cc: tftorrey@tftorrey.com, emacs-orgmode@gnu.org, Rasmus <rasmus@gmx.us>
Subject: Re: Bug: HTML export ignoring CUSTOM_ID properties
Date: Tue, 21 Apr 2015 09:25:13 +0200 [thread overview]
Message-ID: <877ft6aqp2.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <87k2x62gam.wl-n142857@gmail.com> (Daniel Clemente's message of "Tue, 21 Apr 2015 12:37:05 +0700")
Hello,
Daniel Clemente <n142857@gmail.com> writes:
> I also saw this change (diff format):
>
> -<div id="outline-container-sec-1-4-3-1-2" class="outline-6">
> -<h6 id="sec-1-4-3-1-2"><span class="section-number-6">1.4.3.1.2</span> tercer error con stash</h6>
> +<div id="outline-container-orgheadline129" class="outline-6">
> +<h6 id="orgheadline129"><span class="section-number-6">1.4.3.1.2</span> tercer error con stash</h6>
>
> The #sec-1-4-3-1-2 format was better. If I delete section 1.4.3.1.2,
> section 1.5 is still called 1.5, that's good.
And if you delete section 1.4, section 1.5 is no longer called 1.5. So
you need to update IDs most times you change headline numbering. I don't
think it is really better than the current state.
> With a flat numbering like #orgheadline129, deleting any headline
> would change the IDs of all headers after it.
True. This was already the case before, as explained above, or when
using unnumbered headlines.
> And what's the use of IDs if they're not permanent?
The point is that Org knows the ID associated to a given headline, and
provides tools to access them (`org-export-get-reference' for back-end
developers, [[*tercer error con stash]] for users).
I'm not against re-using CUSTOM_ID as in "outline-container-CUSTOM_ID",
but in the general case, where no CUSTOM_ID is defined, the current
state is fine by me.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2015-04-21 7:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-16 23:19 Bug: HTML export ignoring CUSTOM_ID properties T.F. Torrey
2015-04-17 0:20 ` Rasmus
2015-04-17 18:20 ` T.F. Torrey
2015-04-18 13:57 ` Rasmus
2015-04-18 18:26 ` T.F. Torrey
2015-04-18 22:38 ` Aaron Ecay
2015-04-19 3:40 ` T.F. Torrey
2015-04-18 23:08 ` Nicolas Goaziou
2015-04-19 4:20 ` T.F. Torrey
2015-04-19 9:08 ` Nicolas Goaziou
2015-04-19 21:11 ` T.F. Torrey
2015-04-19 14:47 ` Rasmus
2015-04-21 5:37 ` Daniel Clemente
2015-04-21 7:25 ` Nicolas Goaziou [this message]
2015-04-23 18:15 ` Daniel Clemente
2015-04-23 19:21 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877ft6aqp2.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=emacs-orgmode@gnu.org \
--cc=n142857@gmail.com \
--cc=rasmus@gmx.us \
--cc=tftorrey@tftorrey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).