Here here. I agree that the new clarified COMMENT vs. :noexport: functionality makes more sense. And thanks to Nicolas and everyone else for their amazing work. On Wed, Aug 12, 2015 at 9:39 AM, Nicolas Goaziou wrote: > Hello, > > Scott Randby writes: > > > When I started using 8.3, I discovered that the behavior of commented > > headlines had been changed---a change with which I disagree, a change > > I could not find in the release notes, and one which forces me to > > alter a huge number of files. It seems I missed the discussion about > > commented headlines on the mailing list. This is due to my limited > > knowledge of elisp and programming in general, a gap which makes it > > difficult for me to follow the more technical discussions on the > > mailing list. While it has been explained to me that the change is > > a feature, I consider it to be a serious bug since it is not backwards > > compatible. > > I think this change is good. COMMENT status of headlines was muddy > before. The only information about them was the following excerpt (from > Org 8.2.9's manual) > > Also entire subtrees starting with the word ‘COMMENT’ will never be > exported. > > which can mean many things. You extrapolated this definition to one of > its possible meanings, but your definition, AFAIU, was :noexport: > tags's. > > Now there is a clearer definition of a COMMENT headline, and a clear > distinction between COMMENT and :noexport:. > > Note that you don't have to alter any of your files. The following > function can do it for you on the fly, before each export. You can also > used it to effectively alter your files automatically for you. > > (defun my-comment-to-noexport (backend) > (interactive) > (goto-char (point-min)) > (while (re-search-forward "^\\*+.*\\( COMMENT\\)" nil t) > (when (save-match-data (org-in-commented-heading-p t)) > (replace-match "" nil nil nil 1) > (org-set-tags-to (cons "noexport" (org-get-tags)))))) > > (add-hook 'org-export-before-processing-hook #'my-comment-to-noexport) > > I admit it could have been notified in ORG-NEWS. > > > Another issue I had with 8.3 is the deletion of the > > org-latex-with-hyperref variable, something I could not find in the > > release notes (maybe I missed it). I understand that having Org insert > > \hypersetup{...} details is the most desirable situation, but I fail > > to see the harm in keeping org-latex-with-hyperref for those of us who > > needed it in the past. Yes, I figured out a fix, but this is a fix > > that forces me to stick with an outmoded way of doing things, and so > > I consider this deletion to be a bug. > > I'm not sure to understand. What is wrong with setting > `org-latex-hyperref-template' to the empty string? > > This change was introduced in Feb 2014. It is a step forward since we > move from an opt-in/opt-out to a full customizable template. > > I overlooked the fact that this replacement wasn't signaled in ORG-NEWS, > tho. I will try to be more careful for next release. > > > I do understand that all software has bugs, and that everyone working > > on Org is doing so voluntarily (thank you so much for your wonderful > > work). But I was very surprised to find that the evaluation of table > > formulas didn't work in 8.3.1. I could see something like this > > happening in the development version, but it is somewhat mysterious to > > me how such a bug could make its way into a stable release. > > I introduced these changes a short time (three days) before release. > I made an announcement[fn:1] in order to warn there could be some > hiccups in that area. It may be obnoxious for you, but no bug was > reported before release. > > Another example is the recent columns view bug report[fn:2]. The faulty > commit was pushed 2 months ago. Yet no one during development phase > complained about column view being broken. Even a feature freeze period > wouldn't have helped in that case. > > You can't really avoid small glitches after a release. > > > I guess what I want to know, and maybe there is no answer, is how long > > should I wait before upgrading to a stable release? Org is by far the > > most important piece of software I use (I hate it when I can't use > > Org), and bugs (which I know can't be avoided) make it hard, even > > impossible, for me to get my real work done. If there is a way for me > > to minimize encountering bugs, I will appreciate a description of that > > way. > > I suggest to only do regularly minor updates (e.g. 8.3.1 -> 8.3.2). For > major updates, make sure you have some time to spare for bug reporting. > I think we are usually pretty responsive when it comes to bugs. > > > Regards, > > [fn:1] > > [fn:2] > > -- > Nicolas Goaziou > >