Re: [O] [PATCH] org.el: Fix typo
Hi Michaël, Michaël Cadilhac writes: > Smallest possible typo. :-) applied, thanks! -- Bastien
[O] Org brings people together!
Hi all, Just wanted to celebrate the fact that 3M (where I work [1]) was able to host Prof. John Kitchen last week to give two talks: one on his work in catalysis, touching on modeling molecular interactions, and a second one about reproducible research with Org-mode. At 3M we have chapters, which I describe like college clubs, but organized around different technology topics. These are volunteer groups responsible for some ~450 events per year at 3M Center in St. Paul, MN. The events are things like internal product/technology talks, vendor presentations, poster sessions, and hosting professors. When I saw John's mention scimax [2] maybe a year ago and realized he works in an area where we have such a chapter (catalysis), as well as works with Org-mode (relevant to our software chapter), I started scheming and pitched that we invite him. Fast forward a few back and forths about timing later, followed by a sabbatical at Google, and revisiting the idea... and it finally happened! Sadly, I missed the Org talk (CTO was presenting at the same time), but I did go to the first and was able to join him for dinner. I admit that the others at dinner were not quite as programm-y as we were, and might have been playing along laughing we got into the inevitable vim vs. emacs jokes. We were quite amused, though. John will be the second person I've met on the user list. I met Erik Iverson, a long-time user, back in 2011. Turns out he was running the Twin Cities R User Group here and we ended up co-organizing together for a couple years. So far, Org-ers have been 100% awesome in person, and I look forward to running into more down the road. Anyway, just felt like a fun bit of news to share, and hopefully you all can nerd out about Org in person at some point too! It was great to meet you John, great work, great talk, and I look forward to digging into scimax more soon! Best regards, John [1] If 3M isn't immediately recognizable, you might know it for some of it's bigger brands/products like Scotch Tape, Command Strips, Post-It Notes, Filtrete filters, and Scotch-Brite. [2] https://github.com/jkitchin/scimax
Re: [O] exporting to latex and docx not honouring carriage returns to tabbing
Sharon Kimble writes:
> Eric S Fraga writes:
>
>> On Tuesday, 9 Oct 2018 at 12:06, Sharon Kimble wrote:
>>> Brilliant, thanks very much Robert, you've saved the project as I didn't
>>> fancy having to work with the document in LibreOffice. These are the
>>> settings that I've finally gone with -
>>>
>>> #+LaTeX_Header: \parskip=0pt
>>> #+LaTeX_Header: \parindent=2em
>>
>> This is close to the default behaviour for the LaTeX article class. Did you
>> have something setting these to different values?
>
> Yes, I have a custom class called 'my-report' which has no packages
> outlined in it, here it is.
>
> --8<---cut here---start->8---
> #+begin_src emacs-lisp
> (with-eval-after-load 'ox-latex
> (add-to-list 'org-latex-classes
> '("my-report" "\\documentclass{report}
>[NO-DEFAULT-PACKAGES]"
>;;[EXTRA]"
>;;("\\part{%s}" . "\\part*{%s}")
>("\\chapter{%s}" . "\\chapter*{%s}")
>("\\section{%s}" . "\\section*{%s}")
>("\\subsection{%s}" . "\\subsection*{%s}")
>("\\subsubsection{%s}" . "\\subsubsection*{%s}")
>("\\paragraph{%s}" . "\\paragraph*{%s}")
>("\\subparagraph{%s}" . "\\subparagraph*{%s}"
> (custom-set-variables '(org-export-allow-bind-keywords t))
> #+end_src
> [2016-04-14 Thu 08:47]
> [2016-09-09 Fri 00:54]
> [2017-01-17 Tue 13:17]
> http://orgmode.org/worg/org-tutorials/org-latex-export.html
> --8<---cut here---end--->8---
>
>
>>> except for the first paragraph in a new chapter.
>>
>> Yes, the first paragraph after any heading will not be indented. That is
>> also default and is actually what most books use.
>
> Yes, I'm learning, and checking with the book that I'm currently reading :)
>
> Thanks
> Sharon.
While Eric and Robert have provided some really useful tips on some
ad-hoc tweaks you can make to latex/pdf output, I would also encourage
you to look at the many other document styles. As Eric points out, the
tweaks look to be changing the 'report' class to be more like the
'article' class. Have you tried just using the article class instead of
report? Note also there is a 'book' class as well, which may well
produce something more in line with what your after if you are wanting
output which looks more like a published book. Then there are all the
other 'publishers' styles to consider as well as other style packages
like KomaScript, HiTec etc.
While these tweaks are often very useful, they really should be used
sparingly as they can have unforeseen consequences, especially when you
begin to use other packages. It is important to remember that some org
features rely on some of these additional packages to produce good
export results. Once you start 'tweaking' the output, it can quickly
spiral out of control. You fix one thing only to create two new issues.
One of the most common mistakes I see when people start using latex as
the basis for document generation is ad hoc tweaking of the style. This
is an unfortunate consequence of most of us being exposed to traditional
word processors such as MS Word or Libre Office. Producing good quality
documents is a very complex topic and Donald Knuth spent a lot of time
researching all the aspects of type setting and layout to produce a
consistently good and reliable system with TeX. Things have evolved and
we have new requirements (such as on-line documents which are read
electronically and not printed in hard copy). Additional packages have
been added to address these types of enhancements.
The real trick with TeX/LaTeX is to work with the system and not against
it. If you find it necessary to constantly tweak indent, paragraph
spacing, line height, line breaks, etc, then you are probably using the
wrong document style. Try other styles and look for one which meets the
majority of your requirements and only then consider tweaking it. As you
will probably need more than one, you will likely end up with a number
of custom definitions in addition to 'my-report'. I have around 5 base
ones as well as a handful of ones specific to particular jobs/clients
(e.g. include logos, custom headers/footers, title pages etc).
The bad news is that this will probably be somewhat time consuming
initially (there is a huge number of document styles and packages out
there). The good news is that once you have the basic definitions, you
probably won't have to think about this again for ages (my definitions
have been in place for years now).
good luck
Tim
--
Tim Cross
Re: [O] org-clock-in-last bug report
On 2018-10-09, at 18:28, Nicolas Goaziou wrote: > Hello, > > Marcin Borkowski writes: > >> org-clock-in-last used to do nothing when already clocking. Now it >> clocks out and immediately in in the same task. It does that even in >> emacs -Q. >> >> Org mode version 9.1.14 (release_9.1.14-968-gfdb36d) >> >> I'd try to debug it myself, but I'm rather in a hurry now, sorry. >> I looked into git log and I suspect commit a2636b528, which seems to >> change something in that department. > > You're right. *blushes* ;) > > Fixed. > > Thank you. It's me who should thank! You're very fast. Best, -- Marcin Borkowski http://mbork.pl
[O] [PATCH] org.el: Fix typo
Hi there; Smallest possible typo. :-) Cheers; M. From 18461bcddf8549f03f5a57128900c3d56b6a7381 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Cadilhac?= Date: Tue, 9 Oct 2018 17:57:55 +0100 Subject: [PATCH] org.el: Fix typo * lisp/org.el (org-enforce-todo-checkbox-dependencies): Fix typo. TINYCHANGE --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index e3866c2..2b7d16c 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -2822,7 +2822,7 @@ When non-nil, you first need to check off all check boxes before the TODO entry can be switched to DONE. This variable needs to be set before org.el is loaded, and you need to restart Emacs after a change to make the change effective. The only way -to change is while Emacs is running is through the customize interface." +to change it while Emacs is running is through the customize interface." :set (lambda (var val) (set var val) (if val -- 2.19.0
Re: [O] exporting to latex and docx not honouring carriage returns to tabbing
Eric S Fraga writes:
> On Tuesday, 9 Oct 2018 at 12:06, Sharon Kimble wrote:
>> Brilliant, thanks very much Robert, you've saved the project as I didn't
>> fancy having to work with the document in LibreOffice. These are the
>> settings that I've finally gone with -
>>
>> #+LaTeX_Header: \parskip=0pt
>> #+LaTeX_Header: \parindent=2em
>
> This is close to the default behaviour for the LaTeX article class. Did you
> have something setting these to different values?
Yes, I have a custom class called 'my-report' which has no packages
outlined in it, here it is.
--8<---cut here---start->8---
#+begin_src emacs-lisp
(with-eval-after-load 'ox-latex
(add-to-list 'org-latex-classes
'("my-report" "\\documentclass{report}
[NO-DEFAULT-PACKAGES]"
;;[EXTRA]"
;;("\\part{%s}" . "\\part*{%s}")
("\\chapter{%s}" . "\\chapter*{%s}")
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"
(custom-set-variables '(org-export-allow-bind-keywords t))
#+end_src
[2016-04-14 Thu 08:47]
[2016-09-09 Fri 00:54]
[2017-01-17 Tue 13:17]
http://orgmode.org/worg/org-tutorials/org-latex-export.html
--8<---cut here---end--->8---
>> except for the first paragraph in a new chapter.
>
> Yes, the first paragraph after any heading will not be indented. That is
> also default and is actually what most books use.
Yes, I'm learning, and checking with the book that I'm currently reading :)
Thanks
Sharon.
--
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 9.4, fluxbox 1.3.7, emacs 25.3.4, org 9.1.14
signature.asc
Description: PGP signature
Re: [O] Bug: org-goto buffer not honouring org-cycle-separator-lines [9.1.9 (release_9.1.9-65-g5e4542 @ /home/carlos/local/stow/emacs-26/share/emacs/26.1.50/lisp/org/)]
Hello, Carlos Pita writes: > Say I set org-cycle-separator-lines to 1. Now in an org buffer that has > nodes separated by one line, I do C-c C-j to open the org-goto > buffer. Then in the org-goto buffer: > > 1. Every node is suffixed by an ellipsis, even if the only content there >is an empty line. > > 2. Nodes are not separated by an empty line anymore. > > That is, the nodes are "swallowing" the empty lines between them as > their contents, which is exactly what org-cycle-separator-lines = 1 is > intended to avoid. This is intended. According to the `org-goto' docstring: This command works around this by showing a copy of the current buffer in an indirect buffer, in overview mode. Overview mode ignores `org-cycle-separator-lines'. So does `org-goto'. Regards, -- Nicolas Goaziou
Re: [O] org-clock-in-last bug report
Hello, Marcin Borkowski writes: > org-clock-in-last used to do nothing when already clocking. Now it > clocks out and immediately in in the same task. It does that even in > emacs -Q. > > Org mode version 9.1.14 (release_9.1.14-968-gfdb36d) > > I'd try to debug it myself, but I'm rather in a hurry now, sorry. > I looked into git log and I suspect commit a2636b528, which seems to > change something in that department. You're right. *blushes* ;) Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] How to make agenda generation faster
Hello, Adam Porter writes: > My feedback is: there be dragons. ;) The Agenda code is very > complicated and hard to follow, and it's hard to optimize something that > is hard to understand. And hard to maintain. We should really do something about it. > In the long run, to get significant speed improvements, I think it may > be necessary to reimplement the Agenda. Agreed. > However, due to the nature of it (i.e. regexp searches through buffers > to find entries), I don't know how much faster it can be made. I don't > mean that I doubt it can be--I mean that, truly, I don't know, because > it's hard to understand the flow of the code. > > I think that it is already fairly well optimized, given its limitations. > However, an example of a potential improvement would be to refactor it > to work with lexical-binding enabled (which didn't exist when it was > first created); I can't say how much of an improvement it would make, > but my understanding is that code that runs with lexical-binding enabled > is generally faster. Not really. But it's certainly easier to understand since it removes one class of problems. > But doing that would be a non-trivial project, I > think, requiring the fixing of many inevitable regressions in the > process. > > If you haven't seen them already, you may find my org-ql and > org-ql-agenda code useful. org-ql-agenda presents an Agenda-like > buffer. N.B. It does *not* implement most of the Agenda features, but > it does emulate an Org Agenda buffer by setting the appropriate text > properties on entries and formatting them in a similar way. Instead of re-inventing the wheel, or putting efforts into a wheel-like invention, wouldn't it make sense to actually work on Org Agenda itself? I didn't look closely at org-ql, but I had the idea of splitting the Agenda in two distinct parts. One would be responsible for collecting, possibly asynchronously, and caching data from Org documents. The other one would provide a DSL to query and display the results extracted from the output of the first part. The second part could even be made generic enough to be extracted from Org and become some part of Emacs. Displaying filtered data, maybe in a timeline, could be useful for other packages. Unfortunately, I don't have time to work on this. Ah well. So again, wouldn't it be nice to think about Org Agenda-ng? Regards, -- Nicolas Goaziou
[O] [PATCH] lisp/ob-emacs-lisp.el: Remove unecessary printing in body expansion
TINYCHANGE --- lisp/ob-emacs-lisp.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el index 7446af252..322d2882b 100644 --- a/lisp/ob-emacs-lisp.el +++ b/lisp/ob-emacs-lisp.el @@ -54,7 +54,7 @@ their value. It is used as the optional LEXICAL argument to (format "(let (%s)\n%s\n)" (mapconcat (lambda (var) -(format "%S" (print `(,(car var) ',(cdr var) +(format "%S" `(,(car var) ',(cdr var vars "\n ") body -- 2.11.0 signature.asc Description: PGP signature
Re: [O] org-clock-in-last bug report
On 2018-10-09, at 16:25, Marcin Borkowski wrote: > Hi all, > > org-clock-in-last used to do nothing when already clocking. Now it > clocks out and immediately in in the same task. It does that even in > emacs -Q. > > Org mode version 9.1.14 (release_9.1.14-968-gfdb36d) > > I'd try to debug it myself, but I'm rather in a hurry now, sorry. > I looked into git log and I suspect commit a2636b528, which seems to > change something in that department. I had a few spare minutes to check it, and I can confirm that a2636b528 is the culprit. Best, -- Marcin Borkowski http://mbork.pl
[O] org-clock-in-last bug report
Hi all, org-clock-in-last used to do nothing when already clocking. Now it clocks out and immediately in in the same task. It does that even in emacs -Q. Org mode version 9.1.14 (release_9.1.14-968-gfdb36d) I'd try to debug it myself, but I'm rather in a hurry now, sorry. I looked into git log and I suspect commit a2636b528, which seems to change something in that department. Best, -- Marcin Borkowski http://mbork.pl
[O] Again PATH problems with Gnus
Hello, I am sorry to say that I meet again PATH problems with Gnus. In my .profile, in my .bashrc and in /etc/bash.bashrc there are the following lines: PATH=/usr/local/texlive/2018/bin/x86_64-linux:$PATH MANPATH=/usr/local/texlive/2018/texmf/doc/man:$MANPATH INFOPATH=/usr/local/texlive/2018/texmf/doc/info:$INFOPATH export PATH MANPATH INFOPATH and the LaTeX export works with org-mode. But it fails (but sometimes succeed) with mime-htmlize in Gnus, and I do not see how to get a stable solution (except maybe rm -r /usr/local/texlive/ and apt install texlive-full, but I would prefer not to). Your help again is welcome, Regards, -- Joseph
Re: [O] exporting to latex and docx not honouring carriage returns to tabbing
On Tuesday, 9 Oct 2018 at 12:06, Sharon Kimble wrote: > Brilliant, thanks very much Robert, you've saved the project as I didn't > fancy having to work with the document in LibreOffice. These are the > settings that I've finally gone with - > > #+LaTeX_Header: \parskip=0pt > #+LaTeX_Header: \parindent=2em This is close to the default behaviour for the LaTeX article class. Did you have something setting these to different values? > except for the first paragraph in a new chapter. Yes, the first paragraph after any heading will not be indented. That is also default and is actually what most books use. -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.13-783-g97fac4
Re: [O] How to make agenda generation faster
Hi Marcin, I can't advise as to profiling to find out what really bogs down agenda building. I found that log messages do bog it down. I have a lot of recurring tasks, which accumulate log entries for every closing (which in fact means rescheduling to the next day). Every two to three months I prune my org files of those log entries. This significantly speeds up agenda building. HTH, Julius
Re: [O] exporting to latex and docx not honouring carriage returns to tabbing
Robert Klein writes:
> On Mon, 08 Oct 2018 16:54:39 +0100
> Eric S Fraga wrote:
>
>> On Monday, 8 Oct 2018 at 10:56, Sharon Kimble wrote:
>> > My finished output in the pdf will have every line indented/tabbed
>> > to 4 spaces and have a carriage-return at the end of each
>> > paragraph, with no spacings in between paragraphs.
>> >
>> > I can get it how I want in org-mode, but when its exported to latex
>> > and converted into a pdf file, the whole section comes out in one
>> > block of text!
>>
>> Both LaTeX and org define new paragraphs by a blank line. Spaces at
>> the start of a line only have meaning, in org, if the lines are part
>> of a list (and never mean anything in LaTeX).
>>
>> I am not sure exactly what you want to achieve so it is difficult to
>> suggest anything. Try separating your paragraphs with empty lines to
>> see how much closer this gets you to what you want.
>>
>
> What Eric says.
>
> Then try to add to the org-file a line
>
> #+LaTeX_Header: \parskip=0pt
>
> so the spacing between paragraphs is 0. Then add
>
> #+LaTeX_Header: \parindent=0pt
>
> so the first line of a paragraph isn't indented.
>
> If you want to get /all/ the text indented by “4 spaces”, put a line
>
> #+LaTeX: \setlength{\leftskip}{2em}
>
> at the top of your document.
>
>
> If you want only parts indented, put the line before the beginning of
> the part to be indented and put this line after it:
>
> #+LaTeX: \setlength{\leftskip}{0em}
>
> Does this help?
Brilliant, thanks very much Robert, you've saved the project as I didn't
fancy having to work with the document in LibreOffice. These are the
settings that I've finally gone with -
--8<---cut here---start->8---
#+LaTeX_Header: \parskip=0pt
#+LaTeX_Header: \parindent=2em
--8<---cut here---end--->8---
and I've found that having that parindent of 2em gives a very close
approximation of each paragraph beginning with four spaces, except for
the first paragraph in a new chapter. Weird, but true! Just part of what
my finished document has to look like, open any fiction book and you see
what its supposed to look like. When it works right, its beautiful, but
when its wrong, its a right mare!
Thank you very much, and now I've learnt how to do it, it'll make the
whole thing much easier.
Sharon.
--
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
Debian 9.4, fluxbox 1.3.7, emacs 25.3.4, org 9.1.14
signature.asc
Description: PGP signature
Re: [O] Org should follow SemVer conventions [Was: Automatically save the archive file after org-archive-subtree]
Hello, Adam Porter writes: > According to that bug report, the behavior changed when upgrading from > 9.1.2 to 9.1.5. > > I think this shouldn't happen. "Patch"-level releases (incrementing the > third number) should only contain bug fixes. Changes which change > default behavior belong in, at minimum, "minor" releases (incrementing > the second number). [...] > Could Org start doing this and call it Org 10.0? We already do this. It just happens that this particular commit had deeper repercussions than intended. It was then considered as a bugfix and applied on the stable branch. Moreover, next release will be Org 9.2. Not Org 10. I think Org 10 will happen when some major part of Org changes, or when we drop support for older Emacsen, e.g., Emacs 24. Regards, -- Nicolas Goaziou
Re: [O] How to make agenda generation faster
Hi Marcin, My feedback is: there be dragons. ;) The Agenda code is very complicated and hard to follow, and it's hard to optimize something that is hard to understand. In the long run, to get significant speed improvements, I think it may be necessary to reimplement the Agenda. However, due to the nature of it (i.e. regexp searches through buffers to find entries), I don't know how much faster it can be made. I don't mean that I doubt it can be--I mean that, truly, I don't know, because it's hard to understand the flow of the code. I think that it is already fairly well optimized, given its limitations. However, an example of a potential improvement would be to refactor it to work with lexical-binding enabled (which didn't exist when it was first created); I can't say how much of an improvement it would make, but my understanding is that code that runs with lexical-binding enabled is generally faster. But doing that would be a non-trivial project, I think, requiring the fixing of many inevitable regressions in the process. If you haven't seen them already, you may find my org-ql and org-ql-agenda code useful. org-ql-agenda presents an Agenda-like buffer. N.B. It does *not* implement most of the Agenda features, but it does emulate an Org Agenda buffer by setting the appropriate text properties on entries and formatting them in a similar way. It's built on org-ql, which provides per-buffer query caching, which means that generating an org-ql-agenda view for Org buffers that haven't changed since the last view was generated is very fast. It's also written in a more functional way, which I think is easier to follow and modify. Performance of uncached queries/buffers depends on the query--some are relatively fast, while others are slower than the "real" Org Agenda. I think there is significant potential for optimizations, and I'm hoping to implement some in the future. Your feedback would be appreciated! https://github.com/alphapapa/org-ql
Re: [O] exporting to latex and docx not honouring carriage returns to tabbing
On Mon, 08 Oct 2018 16:54:39 +0100
Eric S Fraga wrote:
> On Monday, 8 Oct 2018 at 10:56, Sharon Kimble wrote:
> > My finished output in the pdf will have every line indented/tabbed
> > to 4 spaces and have a carriage-return at the end of each
> > paragraph, with no spacings in between paragraphs.
> >
> > I can get it how I want in org-mode, but when its exported to latex
> > and converted into a pdf file, the whole section comes out in one
> > block of text!
>
> Both LaTeX and org define new paragraphs by a blank line. Spaces at
> the start of a line only have meaning, in org, if the lines are part
> of a list (and never mean anything in LaTeX).
>
> I am not sure exactly what you want to achieve so it is difficult to
> suggest anything. Try separating your paragraphs with empty lines to
> see how much closer this gets you to what you want.
>
What Eric says.
Then try to add to the org-file a line
#+LaTeX_Header: \parskip=0pt
so the spacing between paragraphs is 0. Then add
#+LaTeX_Header: \parindent=0pt
so the first line of a paragraph isn't indented.
If you want to get /all/ the text indented by “4 spaces”, put a line
#+LaTeX: \setlength{\leftskip}{2em}
at the top of your document.
If you want only parts indented, put the line before the beginning of
the part to be indented and put this line after it:
#+LaTeX: \setlength{\leftskip}{0em}
Does this help?
Best regards
Robert
[O] Org should follow SemVer conventions [Was: Automatically save the archive file after org-archive-subtree]
Kodi Arfer writes: > As of > > https://code.orgmode.org/bzg/org-mode/commit/b186d1d7236c0dc397eadeb004c9a17eaffd3aab > > archiving a subtree no longer automatically saves the archive > file. How can I get this behavior back? > > A Debian bug was also opened for this issue: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887332 According to that bug report, the behavior changed when upgrading from 9.1.2 to 9.1.5. I think this shouldn't happen. "Patch"-level releases (incrementing the third number) should only contain bug fixes. Changes which change default behavior belong in, at minimum, "minor" releases (incrementing the second number). Users should be able to freely upgrade from 9.1.x to 9.1.x+1 without having to worry about reading a changelog and adjusting their config to avoid changes in behavior which could lead to data loss. In my own (much smaller) projects, I follow this practice, which is basically SemVer. When I fix bugs, I apply the fixes to the latest stable branch, make a new stable patch-level release, and then merge the fixes into the master branch (in some projects, by rebasing the master branch on top of the stable branch, and in others, by a non-fast-forward merge of the stable branch into the master branch). The master branch becomes the next stable branch when its new features and other changes have been merged for long enough and have no known bugs. New features and refactorings are generally developed in a feature branch and then merged into the master branch when ready, eventually being released in the next stable branch. The master branch is intended to be always usable, but only recommended to users who are willing to potentially encounter bugs in new features or as a result of other significant changes. (In practice, this ends up being the branch used by 99.9% of MELPA users, but that's a MELPA-specific issue.) Most users should use the latest stable branch. This practice also makes it much easier for downstream packagers, like Debian, because changes to the stable branch are ONLY bug fixes. Could Org start doing this and call it Org 10.0?
