From: Rasmus <rasmus@gmx.us>
To: tftorrey@tftorrey.com
Cc: emacs-orgmode@gnu.org
Subject: Re: Bug: HTML export ignoring CUSTOM_ID properties
Date: Sat, 18 Apr 2015 15:57:15 +0200 [thread overview]
Message-ID: <871tjhwnd0.fsf@gmx.us> (raw)
In-Reply-To: <87twwefwgz.fsf@jack.tftorrey.com> (T. F. Torrey's message of "Fri, 17 Apr 2015 11:20:12 -0700")
Hi,
tftorrey@tftorrey.com (T.F. Torrey) writes:
>>> With the latest from Git master, the HTML export ignores CUSTOM_ID
>>> properties for subtrees. I've seen list traffic that the names of the
>>> export ID's are being changed, but this is not intentional, right?
>>
>> It doesn't ignore it, but it is translate to a generic anchor as
>> needed.
>
> Isn't translating it to a generic anchor the same as ignoring it?
> Without a CUSTOM_ID you get a generic anchor. With a CUSTOM_ID you get
> a generic anchor.
You click it and it still works. It's not ignored. Within the syntax it
does the right thing.
> Because I know (knew) the id of the section about Clinton, I could link
> to my page from another document outside Org with a link to
> presidents.html#clinton.
Presumably you could use presidents.org::#clinton still.
> Notice how my CUSTOM_ID's are no longer ID's at all. And simply adding
> "text-" to my CUSTOM_ID's is not an answer. For one thing, CUSTOM_ID
> exports should not change on the breeze of developer whims. For
> another, the ID should be attached to the heading, not the body of the
> text; otherwise, a person following the link would have no idea if it
> went to the Clinton section or not.
>
> Note that this also breaks any CSS styling for the section with the
> CUSTOM_ID (which I also use). If I used a CUSTOM_ID because wanted a
> swanky background for the heading saying "Bill Clinton", the current
> export not only doesn't use that ID, it doesn't encompass the heading
> with his name in.
I have a half-baked patch that restores the old behavior, but I have to
think a bit more about it, and I won't have time today. Nicolas might
also see it in the coming days. E.g. ox-latex has org-latex--label. The
question is whether there should be a solution in ox or whether each
backend should have org-BACKEND--label.
>> Thus, I think it is a bug, unless there is a better way to allow
>> per-section css. I will look at this later unless somebody beets me to it.
>
> Given the lack of outcry, I may be the only one using CUSTOM_ID's for
> HTML export. However, if usage is widespread enough and accidental
> duplicates are a problem enough that this needs to be addressed,
> wouldn't it be better for the exporter to simply report duplicate ID's
> as they are found?
It was changed this week.
> Finally, given that this doesn't appear to work at all in any form of
> its intended usage, how did this even get committed to master? Sure,
> code in master may have bugs, but this is more than a bug; this is
> unusable code that breaks code that worked. Shouldn't it be developed
> on a feature branch or in someone's private repo until it actually
> works?
Master is where we develop things. Nicolas made the change and he's off
this week. Feel free to use Org 8.2.
> Unless there is a quick fix that restores external (non-Org-generated)
> links to sections with CUSTOM_ID's, please revert these changes until
> the development reaches a usable state.
Won't happen.
—Rasmus
--
I hear there's rumors on the, uh, Internets. . .
next prev parent reply other threads:[~2015-04-18 13:57 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871tjhwnd0.fsf@gmx.us \
--to=rasmus@gmx.us \
--cc=emacs-orgmode@gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.