emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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. . .

  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

  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=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 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).