From: Peter Salazar <cycleofsong@gmail.com>
To: Scott Randby <srandby@gmail.com>, emacs-org list <emacs-orgmode@gnu.org>
Subject: Re: Stable releases
Date: Wed, 12 Aug 2015 10:38:42 -0400 [thread overview]
Message-ID: <CAE+_6TwB8e1AZNqW9zExB1csdEtQVLDkM3+nhXPDv3y2bgpU-A@mail.gmail.com> (raw)
In-Reply-To: <87zj1w62yk.fsf@nicolasgoaziou.fr>
[-- Attachment #1: Type: text/plain, Size: 5019 bytes --]
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 <mail@nicolasgoaziou.fr>
wrote:
> Hello,
>
> Scott Randby <srandby@gmail.com> 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] <http://permalink.gmane.org/gmane.emacs.orgmode/99415>
>
> [fn:2] <http://permalink.gmane.org/gmane.emacs.orgmode/99865>
>
> --
> Nicolas Goaziou
>
>
[-- Attachment #2: Type: text/html, Size: 6056 bytes --]
next prev parent reply other threads:[~2015-08-12 14:38 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-11 17:18 Stable releases Scott Randby
2015-08-11 18:33 ` Ista Zahn
2015-08-11 19:34 ` Suvayu Ali
2015-08-11 20:56 ` Rasmus
2015-08-12 16:14 ` Scott Randby
2015-08-12 13:39 ` Nicolas Goaziou
2015-08-12 14:38 ` Peter Salazar [this message]
2015-08-12 15:57 ` Scott Randby
2015-08-12 22:56 ` Rasmus
2015-08-18 16:44 ` Bastien
2015-08-18 17:30 ` Bastien
2015-08-12 17:37 ` Achim Gratz
2015-08-12 19:06 ` Scott Randby
2015-08-13 9:32 ` Eric S Fraga
2015-08-13 13:28 ` Scott Randby
2015-08-18 17:36 ` Bastien
2015-08-18 17:52 ` Scott Randby
2015-08-18 20:40 ` Russell Adams
2015-08-18 22:26 ` Bastien
2015-08-19 20:00 ` Rasmus
2015-08-20 23:03 ` Bastien
2015-08-20 23:56 ` Thomas S. Dye
2015-08-21 7:21 ` Suvayu Ali
2015-08-22 17:32 ` Thomas S. Dye
2015-08-22 17:44 ` Achim Gratz
2015-08-22 17:55 ` Thomas S. Dye
2015-08-22 18:00 ` Achim Gratz
2015-08-22 18:23 ` Thomas S. Dye
2015-08-22 18:53 ` Thomas S. Dye
2015-08-22 18:57 ` Achim Gratz
2015-08-22 19:06 ` Thomas S. Dye
2015-08-21 18:37 ` Rasmus
2015-08-19 8:51 ` Nicolas Goaziou
2015-08-19 9:36 ` Bastien
2015-08-19 14:51 ` Nicolas Goaziou
2015-08-19 19:57 ` Rasmus
2016-01-17 10:12 ` Losing trust in Org: stable org-mode releases and unit tests for basic functionality Karl Voit
2016-01-17 10:30 ` Achim Gratz
2016-01-18 13:47 ` Karl Voit
2016-01-17 13:41 ` Marco Wahl
2016-01-18 14:06 ` Karl Voit
2016-01-19 9:00 ` Marco Wahl
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=CAE+_6TwB8e1AZNqW9zExB1csdEtQVLDkM3+nhXPDv3y2bgpU-A@mail.gmail.com \
--to=cycleofsong@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=srandby@gmail.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).