Re: Bug: HTML export ignoring CUSTOM_ID properties

[tftorrey@tftorrey.com (T.F. Torrey)]

Hello Nicolas,

First, thank you for your incredible work on Org.  I hope you enjoyed
your days off, but I have to admit that your announcement that you were
taking the week off worried me.  I seem to remember we lost Carsten and
Bastien soon after they took a week off.  When (if?) you finally get
burned out and leave, all Org users will feel the loss.

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> "beta" is indeed misleading. I suggest to ignore it.
>
> As Rasmus pointed out, master is where development happens. Some changes
> introduced here may break Org. If one such change makes Org unusable for
> you, you can easily revert Org to an earlier, working, commit, without
> fuss. Of course, we appreciate if you report the problem encountered
> beforehand.

Yes, changes on master can and do occasionally break Org, but they are
*supposed* to work.  You wouldn't leave the spreadsheet functionality in
an unusable state and just tell people to use 8.2.

But yes, it should be a simple matter to revert the commit that caused
the problem for me until the problem can be addressed.  That was the
second thing I looked at.  However, the place where this change happened
is not obvious in the git logs.  I still don't know where it came from.

I did see that most (maybe all) of your changes are accompanied by
tests.  I'm not very familiar with the testing.  Are the tests
restricted to merely checking if the code explodes?  Or is there a
possibility to test whether the code does what it is supposed to do?
Presumably this change that broke functionality passed its tests just
fine.

>> Ha ha.  There are many tools capable of exporting plain-text documents
>> to HTML with predictable and stable ID's.
>
> Considering that not any string is eligible as HTML id (e.g., forbidden
> characters), either these tools are putting restrictions on chosen IDs
> or they are lying.

They aren't lying because they don't claim to allow only valid ID's.
They produce valid ID's on their own, but when a user calls for a
specific ID (the {#clinton} construct in Markdown comes to mind), they
just do what the user tells them to do.  Which is a good thing.

I sense there is a difference of philosophy at play here.

In my view, the purpose of tools such as Org that convert documents to
HTML is to do what the user tells them to do, even if that means
creating invalid HTML.  On many occasions in the past, and probably some
in the present and the future, I have used conversion tools to produce
technically invalid HTML as in intermediate format to be further
processed by XSLT to a final product.  A tool that refused to produce
invalid HTML would be no help at all.  In fact, I'm not aware of any
tool that disallows that except maybe for some beginner level things.

On the contrary, the slant of Org's development lately seems to be first
to make sure users don't make any mistakes, and then to follow their
instructions.

>> As you said, they aren't your changes and it isn't your decision.
>
> I overlooked the problem in HTML and made a mistake. It happens, more
> often than I would like. However, you are not required to be obnoxious
> about it. It helps no one.

Your mistakes are very rare, and your work is sincerely appreciated.  I
think your comment about my response is out of context, and I'm not sure
your final statement is true.  My polite comments were summarily
dismissed, but now anyone who depended on CUSTOM_ID has been helped.

> The problem should be fixed in 0449b785b4b58ec16e1aac126634de70eee519a4.
> Thank you for reporting it.

Thank you for your prompt action, but can I ask what you mean by
"fixed"?  Have you decided to revert CUSTOM_ID to its previous
functionality?  Are you still planning on changing its functionality
and/or meaning?  Are you still planning on throwing warnings or errors in
the event of duplicate or invalid CUSTOM_ID's?

Best,
Terry
-- 
T.F. Torrey