From: tftorrey@tftorrey.com (T.F. Torrey)
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: emacs-orgmode@gnu.org, rasmus@gmx.us
Subject: Re: Bug: HTML export ignoring CUSTOM_ID properties
Date: Sat, 18 Apr 2015 21:20:20 -0700 [thread overview]
Message-ID: <87pp7021h7.fsf@jack.tftorrey.com> (raw)
In-Reply-To: <87egnhm3ue.fsf@nicolasgoaziou.fr> (message from Nicolas Goaziou on Sun, 19 Apr 2015 01:08:57 +0200)
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
next prev parent reply other threads:[~2015-04-19 4:20 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 [this message]
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=87pp7021h7.fsf@jack.tftorrey.com \
--to=tftorrey@tftorrey.com \
--cc=emacs-orgmode@gnu.org \
--cc=mail@nicolasgoaziou.fr \
--cc=rasmus@gmx.us \
/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).