From mboxrd@z Thu Jan 1 00:00:00 1970 From: tftorrey@tftorrey.com (T.F. Torrey) Subject: Re: Bug: HTML export ignoring CUSTOM_ID properties Date: Sat, 18 Apr 2015 21:20:20 -0700 Message-ID: <87pp7021h7.fsf@jack.tftorrey.com> References: <87egnhm3ue.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjgik-0007ST-3I for emacs-orgmode@gnu.org; Sun, 19 Apr 2015 00:20:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yjgig-0003r1-SP for emacs-orgmode@gnu.org; Sun, 19 Apr 2015 00:20:38 -0400 Received: from relay5-d.mail.gandi.net ([2001:4b98:c:538::197]:42154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjgig-0003qj-8o for emacs-orgmode@gnu.org; Sun, 19 Apr 2015 00:20:34 -0400 In-Reply-To: <87egnhm3ue.fsf@nicolasgoaziou.fr> (message from Nicolas Goaziou on Sun, 19 Apr 2015 01:08:57 +0200) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org, rasmus@gmx.us 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 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