Re: [O] Stable releases
Achim Gratz writes: > Thomas S. Dye writes: >> However, the package manager doesn't (yet) recognize this package and >> when I download ob-* packages, org-2015* is also downloaded. > > Did you restart Emacs? The package files need not be byte-compiled (and > shouldn't, IMHO). No, but when I did that just now everything worked as expected. Many thanks! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Stable releases
Thomas S. Dye writes: > However, the package manager doesn't (yet) recognize this package and > when I download ob-* packages, org-2015* is also downloaded. Did you restart Emacs? The package files need not be byte-compiled (and shouldn't, IMHO). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] Stable releases
Thomas S. Dye writes: > Achim Gratz writes: > >> Thomas S. Dye writes: >>> Excellent. Thanks! Would it be useful to distribute org-21991231 on >>> elpa? >> >> No, not at all… Unless you want to make sure that noone ever gets an >> update until the next millenium starts. > > No, I don't want that. Thanks for the explanation. I'm satisfied > knowing I won't inadvertently download Org mode from elpa again, at > least until several months after my 247th birthday :) Oops, I spoke too soon. I created the org-21991231 folder where all the other emacs packages are installed, added org-pkg.el with the line you suggested, and byte-compiled to org-pkg.elc. However, the package manager doesn't (yet) recognize this package and when I download ob-* packages, org-2015* is also downloaded. Also, org-21991231 doesn't show up in the package manager. Is there a registration step? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Stable releases
Achim Gratz writes: > Thomas S. Dye writes: >> Excellent. Thanks! Would it be useful to distribute org-21991231 on >> elpa? > > No, not at all… Unless you want to make sure that noone ever gets an > update until the next millenium starts. No, I don't want that. Thanks for the explanation. I'm satisfied knowing I won't inadvertently download Org mode from elpa again, at least until several months after my 247th birthday :) All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Stable releases
Thomas S. Dye writes: > Excellent. Thanks! Would it be useful to distribute org-21991231 on > elpa? No, not at all… Unless you want to make sure that noone ever gets an update until the next millenium starts. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [O] Stable releases
Aloha Achim, Achim Gratz writes: > Thomas S. Dye writes: >> I do have a technical question that you or someone else on the list >> might be able to answer for me. When I downloaded the Babel languages >> from melpa just now, the elpa version of Org mode was also downloaded >> and installed, even though I didn't ask for it. Why is this? > > Although you don't say which package you tried, I would guess that the > "org" package is specified as a dependency, likely with some minimum > version. I tried the ob-* packages and I'm not sure which one(s) might have triggered this. > >> Can it be disabled? Must the elpa Org mode be installed and activated >> in order for the Org mode packages to work? > > From the point of package manager anything installed from the outside > doesn't exist. You can fake that in various way, for instance by > creating a package directory "org-21991231" and putting an org-pkg.el > with > > (define-package "org" "21991231" "Fake Org package for dependency resolution" > 'nil) > > in it. Excellent. Thanks! Would it be useful to distribute org-21991231 on elpa? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Stable releases
Thomas S. Dye writes: > I do have a technical question that you or someone else on the list > might be able to answer for me. When I downloaded the Babel languages > from melpa just now, the elpa version of Org mode was also downloaded > and installed, even though I didn't ask for it. Why is this? Although you don't say which package you tried, I would guess that the "org" package is specified as a dependency, likely with some minimum version. > Can it be disabled? Must the elpa Org mode be installed and activated > in order for the Org mode packages to work? >From the point of package manager anything installed from the outside doesn't exist. You can fake that in various way, for instance by creating a package directory "org-21991231" and putting an org-pkg.el with (define-package "org" "21991231" "Fake Org package for dependency resolution" 'nil) in it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] Stable releases
Suvayu Ali writes: > Hi Tom, > > On Thu, Aug 20, 2015 at 01:56:43PM -1000, Thomas S. Dye wrote: >> >> Bastien writes: >> >> > Hi Rasmus, >> > >> > Rasmus writes: >> > >> >> One data point: I can absolutely not be bothered using anything that is >> >> not at least in contrib. >> > >> > Just out of curiosity: don't you use the Emacs package system at all? >> > >> > I used not to use it, but thanks to recent improvements, I find it >> > quite good now -- and I would not mind using Org packages from there. >> >> The package system appears to be quite popular in the Org mode world. > > The summary you provide below is very impressive, thanks for compiling > it. It would be a nice addition to worg, with a date attached to it of > course! It's bound to go stale at some point :-p. > > However I would like to point out, the documentation for many of these > extensions is rather spreadout and thin. So I agree with Rasmus, as in, > contrib is much more accessible, but I think it also encourages authors > to contribute documentation on worg (after all it's in the official > repository). That said, I'm not sure why some of the extensions, like > ox-reveal, are _not_ in contrib. AFAIU, it's quite mature. Rasmus' ranking of org mode sources interested me, so I tried to satisfy my curiosity is all. I hope you didn't think I was disagreeing with his decision not to be bothered using Org mode packages. I certainly understand it. I made the same decision wrt the elpa version of Org mode after struggling with mixed installations--life is too short! I do have a technical question that you or someone else on the list might be able to answer for me. When I downloaded the Babel languages from melpa just now, the elpa version of Org mode was also downloaded and installed, even though I didn't ask for it. Why is this? Can it be disabled? Must the elpa Org mode be installed and activated in order for the Org mode packages to work? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Stable releases
Hi, >> One data point: I can absolutely not be bothered using anything that is >> not at least in contrib. > > Just out of curiosity: don't you use the Emacs package system at all? At work I cannot use package.el. At home, the search cost associated with checking out org-random-mode is higher. If I'm lucky I can figure out how it works on github. The only org package I use from outside of org-mode.git is org-caldav. > I used not to use it, but thanks to recent improvements, I find it > quite good now -- and I would not mind using Org packages from there. Every package you rely on, that is not in the Emacs tarball is a potential liability. I believe I have had issues with conflicting company packages previously. Rasmus -- There are known knowns; there are things we know that we know
Re: [O] Stable releases
Hi Tom, On Thu, Aug 20, 2015 at 01:56:43PM -1000, Thomas S. Dye wrote: > > Bastien writes: > > > Hi Rasmus, > > > > Rasmus writes: > > > >> One data point: I can absolutely not be bothered using anything that is > >> not at least in contrib. > > > > Just out of curiosity: don't you use the Emacs package system at all? > > > > I used not to use it, but thanks to recent improvements, I find it > > quite good now -- and I would not mind using Org packages from there. > > The package system appears to be quite popular in the Org mode world. The summary you provide below is very impressive, thanks for compiling it. It would be a nice addition to worg, with a date attached to it of course! It's bound to go stale at some point :-p. However I would like to point out, the documentation for many of these extensions is rather spreadout and thin. So I agree with Rasmus, as in, contrib is much more accessible, but I think it also encourages authors to contribute documentation on worg (after all it's in the official repository). That said, I'm not sure why some of the extensions, like ox-reveal, are _not_ in contrib. AFAIU, it's quite mature. Cheers, > There are a dozen ob-* languages distributed by the package system > vs. eight in contrib. There are fifteen ox-* exporters available > through the package system vs. eleven in contrib. > > Download statistics from Melpa indicate several of the packages are > quite popular. ox-reveal has been downloaded more than 4,000 times, and > ox-pandoc and ox-gfm (Github flavored markup) more than 1,000 times. > The babel languages are less popular, but ob-browser (for html), > ob-ipython, ob-mongo, and ob-sml have all been downloaded more than 300 > times. > > Melpa has 91 org-* packages. The packages evil-org, org-bullets, and > org-fstree have all been downloaded more than 10,000 times. There are > ten others with more than 1,000 downloads. -- Suvayu Open source is the future. It sets us free.
Re: [O] Stable releases
Bastien writes: > Hi Rasmus, > > Rasmus writes: > >> One data point: I can absolutely not be bothered using anything that is >> not at least in contrib. > > Just out of curiosity: don't you use the Emacs package system at all? > > I used not to use it, but thanks to recent improvements, I find it > quite good now -- and I would not mind using Org packages from there. The package system appears to be quite popular in the Org mode world. There are a dozen ob-* languages distributed by the package system vs. eight in contrib. There are fifteen ox-* exporters available through the package system vs. eleven in contrib. Download statistics from Melpa indicate several of the packages are quite popular. ox-reveal has been downloaded more than 4,000 times, and ox-pandoc and ox-gfm (Github flavored markup) more than 1,000 times. The babel languages are less popular, but ob-browser (for html), ob-ipython, ob-mongo, and ob-sml have all been downloaded more than 300 times. Melpa has 91 org-* packages. The packages evil-org, org-bullets, and org-fstree have all been downloaded more than 10,000 times. There are ten others with more than 1,000 downloads. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Stable releases
Hi Rasmus, Rasmus writes: > One data point: I can absolutely not be bothered using anything that is > not at least in contrib. Just out of curiosity: don't you use the Emacs package system at all? I used not to use it, but thanks to recent improvements, I find it quite good now -- and I would not mind using Org packages from there. -- Bastien
Re: [O] Stable releases
Bastien writes: > In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as > I don't see why we needed to remove this option too. Because too many cooks spoil the broth. It's a bad idea to have two variables controlling the same thing. You can put in nil in template if you don't want it. Rasmus -- There are known knowns; there are things we know that we know
Re: [O] Stable releases
Russell Adams writes: > On Tue, Aug 18, 2015 at 07:36:00PM +0200, Bastien wrote: >> Hi Scott, >> > >> the main reason why 8.3 was not as "stable" as it should have been is >> that I've been releasing it too quickly, after having been inactive >> way too long. >> >> It's kind of a miracle that Org development could continue without an >> active "official" maintainer for so long, and we owe a lot to Nicolas >> and other contributors for this. > > Bastien, > > As a Org user since 2006 I've watched and appreciated how much time > and effort yourself and Carsten have put into maintainership. This > significant commitment brings about the following question: > > Is Org large enough that it would benefit from being broken into more > pieces? > > For instance a stable core that includes only the major mode itself, > which you continue to maintain. This defines the file syntax and > includes core features which require little to no external programs or > libraries. > > Then could you break out the exporters, babel, and many of the other > sub-features into "plugins" that could be maintained separately by > others, and they depend back to the core version? > > My impression has been that the core Org functionality has been stable > for quite a while, and the org ecosystem grows by leaps and bounds as > new users expand the incredibly flexible syntax to work for their use > case. It's nice to have "batteries included". This is also the strength of programming languages such as python, emacs-lisp, and to a lesser extend R. One data point: I can absolutely not be bothered using anything that is not at least in contrib. Rasmus -- A clever person solves a problem. A wise person avoids it
Re: [O] Stable releases
Bastien writes: > Nicolas Goaziou writes: > >> At the bare minimum `org-latex-with-hyperref' should be an obsolete >> alias for `org-latex-hyperref-template', and the latter should support >> nil as a possible value. > > If you want, please go ahead. Done. Regards,
Re: [O] Stable releases
Hi Nicolas, Nicolas Goaziou writes: > I disagree. Most bugs reported were introduced months ago. Waiting more > wouldn't have helped here. s/quickly/hastily > `org-latex-hyperref-template' is more general that > `org-latex-with-hyperref'. Now, we have two variables which can > contradict each other (e.g., setting with-hyperref to t and > hyperref-template to the empty string). This is not very good, IMO. > > At the bare minimum `org-latex-with-hyperref' should be an obsolete > alias for `org-latex-hyperref-template', and the latter should support > nil as a possible value. If you want, please go ahead. Thanks, -- Bastien
Re: [O] Stable releases
Hello, Bastien writes: > that I've been releasing it too quickly, after having been inactive > way too long. I disagree. Most bugs reported were introduced months ago. Waiting more wouldn't have helped here. > So all the advice you got is good, but think of 8.3 as a "come back" > release, with problems that are largely due to me not paying attention > enough to all those small details that make a good release. ... > In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as > I don't see why we needed to remove this option too. `org-latex-hyperref-template' is more general that `org-latex-with-hyperref'. Now, we have two variables which can contradict each other (e.g., setting with-hyperref to t and hyperref-template to the empty string). This is not very good, IMO. At the bare minimum `org-latex-with-hyperref' should be an obsolete alias for `org-latex-hyperref-template', and the latter should support nil as a possible value. Regards, -- Nicolas Goaziou
Re: [O] Stable releases
Hi Russell, Russell Adams writes: > Could we reduce the amount of maintenance to the core if we separate > the rapidly changing plugins to separate projects? I have a plan to let contrib/* live its own life outside of the core Org repository. I hope this will encourage a sense of ownership for those libraries. But most bug reports and feature requests are against Org's core, so I'm not sure a modular approach would really alleviate the task. Of course, maybe this intuition is wrong, and many bug reports are against non-core features. In any case, I think we just need to stick to our "low floor / high ceiling" approach: be as inclusive and welcome as possible, and give as much freedom as required to regular contributors. Finally, if I feel like I need donations to dedicate more time to Org, I won't hesitate to ask for support. -- Bastien
Re: [O] Stable releases
On Tue, Aug 18, 2015 at 07:36:00PM +0200, Bastien wrote: > Hi Scott, > > the main reason why 8.3 was not as "stable" as it should have been is > that I've been releasing it too quickly, after having been inactive > way too long. > > It's kind of a miracle that Org development could continue without an > active "official" maintainer for so long, and we owe a lot to Nicolas > and other contributors for this. Bastien, As a Org user since 2006 I've watched and appreciated how much time and effort yourself and Carsten have put into maintainership. This significant commitment brings about the following question: Is Org large enough that it would benefit from being broken into more pieces? For instance a stable core that includes only the major mode itself, which you continue to maintain. This defines the file syntax and includes core features which require little to no external programs or libraries. Then could you break out the exporters, babel, and many of the other sub-features into "plugins" that could be maintained separately by others, and they depend back to the core version? My impression has been that the core Org functionality has been stable for quite a while, and the org ecosystem grows by leaps and bounds as new users expand the incredibly flexible syntax to work for their use case. Could we reduce the amount of maintenance to the core if we separate the rapidly changing plugins to separate projects? Sorry if this has been hashed before, but I felt it appropriate to ask. Thanks. -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Re: [O] Stable releases
On 08/18/2015 01:36 PM, Bastien wrote: Hi Scott, the main reason why 8.3 was not as "stable" as it should have been is that I've been releasing it too quickly, after having been inactive way too long. It's kind of a miracle that Org development could continue without an active "official" maintainer for so long, and we owe a lot to Nicolas and other contributors for this. So all the advice you got is good, but think of 8.3 as a "come back" release, with problems that are largely due to me not paying attention enough to all those small details that make a good release. The cure is to deliver major releases at a steady pace, and I'm sure having a "release team" will help a lot. I've learned a lot from the advice I've been given, and I'm now better equipped to handle updates. In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as I don't see why we needed to remove this option too. I appreciate this a great deal. It will make my life easier to have this variable back in Org. Scott Randby Thanks,
Re: [O] Stable releases
Bastien writes: > This is not too late -- can you add a note in etc/ORG-NEWS in maint > about this change? Forget about this, I've reintroduced org-latex-with-hyperref. -- Bastien
Re: [O] Stable releases
Hi Scott, the main reason why 8.3 was not as "stable" as it should have been is that I've been releasing it too quickly, after having been inactive way too long. It's kind of a miracle that Org development could continue without an active "official" maintainer for so long, and we owe a lot to Nicolas and other contributors for this. So all the advice you got is good, but think of 8.3 as a "come back" release, with problems that are largely due to me not paying attention enough to all those small details that make a good release. The cure is to deliver major releases at a steady pace, and I'm sure having a "release team" will help a lot. In the meantime, `org-latex-with-hyperref' will be back in 8.3.2 as I don't see why we needed to remove this option too. Thanks, -- Bastien
Re: [O] Stable releases
Hi Nicolas, Nicolas Goaziou writes: > 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. This is not too late -- can you add a note in etc/ORG-NEWS in maint about this change? Thanks, -- Bastien
Re: [O] Stable releases
On 08/13/2015 05:32 AM, Eric S Fraga wrote: On Wednesday, 12 Aug 2015 at 15:06, Scott Randby wrote: [...] If there are no stable releases, then maybe the web site should not say: "Stable version 8.3.1 (Aug. 2015)." Perhaps "stable" should just be eliminated from that phrase. Certainly, the use of "stable" confused me. I guess it's a matter of interpretation. The word stable can mean different things. In this context, it is the opposite of labile and specifically in comparison with the continually changing git version. Stable does not unfortunately mean "bug-free" nor does it mean anything with respect to the previous "stable" version. I never expect any version to be bug free.
Re: [O] Stable releases
On Wednesday, 12 Aug 2015 at 15:06, Scott Randby wrote: [...] > If there are no stable releases, then maybe the web site should not > say: "Stable version 8.3.1 (Aug. 2015)." Perhaps "stable" should just > be eliminated from that phrase. Certainly, the use of "stable" > confused me. I guess it's a matter of interpretation. The word stable can mean different things. In this context, it is the opposite of labile and specifically in comparison with the continually changing git version. Stable does not unfortunately mean "bug-free" nor does it mean anything with respect to the previous "stable" version. -- : Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.2, Org release_8.3.1-34-gb911f1
Re: [O] Stable releases
Scott Randby writes:
> I don't understand what is wrong with keeping
> org-latex-with-hyperref. It is easy enough for me to set the variable
> locally for old files while I can use the default \hypersetup{...} for
> new files. Making org-latex-hyperref-template an empty string means I
> cannot use the built-in default template.
You can use file-variable or BIND to set org-latex-with-hyperref to the
empty string or nil. We could include org-latex-with-hyperref, but I
don't see any advantage in having two ways to disable hyperref setup...
Also, org-latex-with-hyperref does not seem to have ox-publish support,
skimming 8.2.10 briefly.
Still, the ORG-NEWS entry could've been better.
Rasmus
--
Warning: Everything saved will be lost
Re: [O] Stable releases
On 08/12/2015 01:37 PM, Achim Gratz wrote: Scott Randby writes: While I've used Org's development version in the past, I stopped doing that due to my failure to learn how to use git (no time) and other issues. Now, I only use the stable releases. But the latest 8.3 release doesn't seem so stable to me, so I'd like some clarification about what the Org maintainers mean by a stable release. Perhaps this is too vague, so let me explain a bit. There are no stable releases, but major and minor ones (see README_maintainer). Major releases are developed in the master branch and include backwards-incompatible changes as well as new and removed features. Minor releases are made from the maint branch and are kept backwards compatible to the last major release (only bug fixes, no new features, no feature removal). If there are no stable releases, then maybe the web site should not say: "Stable version 8.3.1 (Aug. 2015)." Perhaps "stable" should just be eliminated from that phrase. Certainly, the use of "stable" confused me. Scott
Re: [O] Stable releases
Scott Randby writes: > While I've used Org's development version in the past, I stopped doing > that due to my failure to learn how to use git (no time) and other > issues. Now, I only use the stable releases. But the latest 8.3 > release doesn't seem so stable to me, so I'd like some clarification > about what the Org maintainers mean by a stable release. Perhaps this > is too vague, so let me explain a bit. There are no stable releases, but major and minor ones (see README_maintainer). Major releases are developed in the master branch and include backwards-incompatible changes as well as new and removed features. Minor releases are made from the maint branch and are kept backwards compatible to the last major release (only bug fixes, no new features, no feature removal). > Normally, I wait many months before upgrading Org to a new stable > release, but when 8.3 was released, I upgraded right away (from > 8.2.10) since I have a new machine on which I installed Emacs 24.5. I > read through the release notes for anything that might give me > problems and didn't see anything. Since the NEWS file isn't automatically generated, there are some holes to be expected after two years of development. That's not an excuse, mind you, and everyone should strive to be more diligent in keeping the code changes synced up with the documentation. > 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. As always when it comes to updates, there is the camp that says you should keep with the flow and make many small changes in doing so and the other one that says to wait unltil the last moment and then do the big-bang change of everything. In your case it seems you need to plan for some conversion time whenever you skip to a new major release. I don't see why you would skip minor releases though. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] Stable releases
On 08/11/2015 04:56 PM, Rasmus wrote: Hi, The definition of a major release is in README_maintainer: Main releases are made whenever Org is in a state where the feature set is consistent and we feel that the features that are implemented is something we want to support in the future. AFAIK, Org 8.2.10 ships with Emacs 24.5 and you can use that. I agree that the changes you mentioned should be in ORG-NEWS. You can help by testing the master version against your files once in a while and let us know of breakages. This is very helpful. Thank you. Rasmus
Re: [O] Stable releases
On 08/12/2015 09: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)
This function won't work for me because I use COMMENT in two different
ways. I didn't extrapolate the meaning of COMMENT, I copied its various
uses from files that other people have posted in various places. It is
more flexible for COMMENT to mean various things than it is for it to be
pigeonholed to one narrow function. COMMENT wasn't broken until 8.3.
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?
I don't understand what is wrong with keeping org-latex-with-hyperref.
It is easy enough for me to set the variable locally for old files while
I can use the default \hypersetup{...} for new files. Making
org-latex-hyperref-template an empty string means I cannot use the
built-in default template.
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'm not sure why I didn't notice a problem before 8.3. Perhaps it is due
to my irregular updating.
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.
I don't consider the bug to be obnoxious, I'm just trying to understand
what is meant by a stable 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.
Yes, I understand.
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 th
Re: [O] Stable releases
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
>
>
Re: [O] Stable releases
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
Re: [O] Stable releases
Hi, The definition of a major release is in README_maintainer: Main releases are made whenever Org is in a state where the feature set is consistent and we feel that the features that are implemented is something we want to support in the future. AFAIK, Org 8.2.10 ships with Emacs 24.5 and you can use that. I agree that the changes you mentioned should be in ORG-NEWS. You can help by testing the master version against your files once in a while and let us know of breakages. Rasmus -- The Kids call him Billy the Saint
Re: [O] Stable releases
On Tue, Aug 11, 2015 at 02:33:18PM -0400, Ista Zahn wrote:
> On Tue, Aug 11, 2015 at 1:18 PM, Scott Randby wrote:
> >
> > 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?
>
> One strategy is keeping an eye on the mailing list and waiting for bug
> reports to die down before upgrading.
I would like to add, the community always needs help, and writing code
is not the only way to do that. From your message it seems to me you
have a rather elaborate use for Org. It might serve as a great test
case. If you follow the list regularly, then you could help by testing
the maint branch from time to time (or even master, up to you).
You do not need to know how to use git, you have two options:
- simply download the tarballs from the gitweb interface (see the
"snapshot" links, http://orgmode.org/w/org-mode.git),
- use elpa (either GNU, Org's own)
As for git, I have included the bash function I use to update Org once a
week. If you are interested, feel free to ask me Git questions
off-list.
function update_org() {
pushd ~/build/org-mode # my Org repo and install directory
local dorebase=$(git rev-list origin/master..master|wc -l)
git stash
git checkout master
if [[ $dorebase -gt 0 ]]; then
git pull --rebase --stat
else
git pull
fi
if [ $? == 0 ]; then
echo "+++ Check if merged successfully. +++"
echo "==> Want to continue?"
select yesorno in "Yes" "No"; do
case $yesorno in
Yes)
echo "+++ Building Org-mode $(git branch|egrep '\*')
+++";
make compile autoloads info "$@" &> log
[ $? -ne 0 ] && echo "+++ Build failed
+++" && break;
echo "+++ Installing Info files +++";
make install-info
break;;
No)
echo "Aborting on user command.";
break;;
*)
echo "==> Choose Yes or No by typing 1 or 2."
esac
done
else
echo "Merge failed, aborting."
fi
popd
}
Hope this helps,
--
Suvayu
Open source is the future. It sets us free.
Re: [O] Stable releases
On Tue, Aug 11, 2015 at 1:18 PM, Scott Randby wrote: > While I've used Org's development version in the past, I stopped doing that > due to my failure to learn how to use git (no time) and other issues. Now, I > only use the stable releases. But the latest 8.3 release doesn't seem so > stable to me, so I'd like some clarification about what the Org maintainers > mean by a stable release. Perhaps this is too vague, so let me explain a > bit. [snip] > > 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? One strategy is keeping an eye on the mailing list and waiting for bug reports to die down before upgrading. 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. > > Scott Randby >
