From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Salazar Subject: Re: Stable releases Date: Wed, 12 Aug 2015 10:38:42 -0400 Message-ID: References: <55CA2E6B.4060102@gmail.com> <87zj1w62yk.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd90c6eda65f6051d1e2c10 Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPXB0-0002G1-OB for emacs-orgmode@gnu.org; Wed, 12 Aug 2015 10:38:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPXAx-0003Pf-KD for emacs-orgmode@gnu.org; Wed, 12 Aug 2015 10:38:46 -0400 Received: from mail-pa0-x22f.google.com ([2607:f8b0:400e:c03::22f]:33727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPXAx-0003OR-96 for emacs-orgmode@gnu.org; Wed, 12 Aug 2015 10:38:43 -0400 Received: by pabyb7 with SMTP id yb7so15883670pab.0 for ; Wed, 12 Aug 2015 07:38:42 -0700 (PDT) In-Reply-To: <87zj1w62yk.fsf@nicolasgoaziou.fr> 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: Scott Randby , emacs-org list --047d7bd90c6eda65f6051d1e2c10 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=98COMMENT=E2=80=99 w= ill 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 > > --047d7bd90c6eda65f6051d1e2c10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here here. I agree that the new clarified COMMENT vs. :noe= xport: functionality makes more sense.=C2=A0And thanks to Nicolas and every= one else for their amazing work.=C2=A0

=
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<= br> > headlines had been changed---a change with which I disagree, a change<= br> > 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)

=C2=A0 Also entire subtrees starting with the word =E2=80=98COMMENT=E2=80= =99 will never be
=C2=A0 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.

=C2=A0 (defun my-comment-to-noexport (backend)
=C2=A0 =C2=A0 (interactive)
=C2=A0 =C2=A0 (goto-char (point-min))
=C2=A0 =C2=A0 (while (re-search-forward "^\\*+.*\\( COMMENT\\)" n= il t)
=C2=A0 =C2=A0 =C2=A0 (when (save-match-data (org-in-commented-heading-p t))=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (replace-match "" nil nil nil 1)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (org-set-tags-to (cons "noexport" (or= g-get-tags))))))

=C2=A0 (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<= br> > 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<= br> > 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<= br> > impossible, for me to get my real work done. If there is a way for me<= br> > 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<= br> 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.emac= s.orgmode/99415>

[fn:2] <http://permalink.gmane.org/gmane.emac= s.orgmode/99865>

--
Nicolas Goaziou


--047d7bd90c6eda65f6051d1e2c10--