Re: [O] [PATCH 03/10] Clean up various org-babel-*-maybe commands
Hi Bastien, Thanks for your comments. 2013ko apirilak 3an, Bastien-ek idatzi zuen: [...] org-babel-get-src-block-info is a potentially expensive operation, which is why its ‘light’ argument exists. But in any case, it is overkill to query the whole info, if all that is needed is whether point is in a block or not. Factor the simplified common code out into a macro. The let-bound info variable is not only used to check if we are within a src block, it is also passed as an argument to functions, see the ^^ marks below. All of these functions will re-calculate the info if it is not passed, using org-babel-get-src-block-info. So not passing it does no harm. --- lisp/ob-core.el | 31 +-- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 723aa9d..283628e 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -365,15 +365,22 @@ of potentially harmful code. (or (org-babel-execute-src-block-maybe) (org-babel-lob-execute-maybe))) +(defmacro org-babel-when-in-src-block (rest body) + `(if (or (org-babel-where-is-src-block-head) + (org-babel-get-inline-src-block-matches)) + (progn + ,@body + t) + nil)) (Please always add a docstring of defuns and defmacros) I’ll resend the patch with a docstring and fixing the commit message problems you and Achim pointed out. [...] @@ -433,8 +436,8 @@ then run `org-babel-load-in-session'. Detect if this is context for a org-babel src-block and if so then run `org-babel-pop-to-session'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info (progn (org-babel-pop-to-session current-prefix-arg info) t) nil))) + (org-babel-when-in-src-block + (org-babel-pop-to-session current-prefix-arg))) (Let's use the current name `org-babel-switch-to-session' instead of the obsolete alias.) OK. Maybe we don't always need to pass the info as an argument, but at least for this last example it is needed. o-b-switch-to-session does nothing with the info argument but pass it along to o-b-initiate-session, which will recalculate it if it is missing. So it takes 2 hops in contrast to the 1 in the other cases, but it still gets recalculated. -- Aaron Ecay
Re: [O] [PATCH 05/10] Remove info arg from several org-babel functions
Hi Eric, Thanks for your comments on this and all the patches. 2013ko apirilak 3an, Eric Schulte-ek idatzi zuen: Aaron Ecay aarone...@gmail.com writes: * lisp/ob-core.el (org-babel-load-in-session), (org-babel-initiate-session), (org-babel-switch-to-session) (org-babel-switch-to-session-with-code): Remove info optional arg The info arg is threaded through this code, but never used by callers (at least in org code). The rgrep command disagrees with this last statement. ./ob-core.el:411: (progn (org-babel-load-in-session current-prefix-arg info) t) This was removed in patch #3 of the series. I tried to make all the patches independent of each other, but this dependency did slip in. I can squash the two patches if you’d prefer. -- Aaron Ecay
Re: [O] [PATCH 04/10] Add 'light argument to some uses of org-babel-get-src-block-info
Hi Eric, 2013ko apirilak 3an, Eric Schulte-ek idatzi zuen: Aaron Ecay aarone...@gmail.com writes: * lisp/ob-core.el (org-babel-do-key-sequence-in-edit-buffer), (org-babel-expand-noweb-references), * lisp/ob-tangle.el (org-babel-tangle): Use 'light argument to `org-babel-get-src-block-info'. I'd like to apply this patch, however tracing the effects of these changes can be tricky and `org-babel-expand-noweb-references' and `org-babel-tangle' are both core functions. Have you run the test suite to confirm that these changes don't break any existing tests? The test suite gives no failures with this patch. -- Aaron Ecay
Re: [O] Superscripts and subscripts
upgrading to trunk gives me the same behaviour as John reported,
which, while not perfect, is better for tensors.
On Wed, Apr 17, 2013 at 10:54 PM, Daniel Mahler dmah...@gmail.com wrote:
In my .emacs I have
(custom-set-variables
;;...
'(org-pretty-entities t)
'(org-use-sub-superscripts (quote {}))
;;...
)
but I get the opposite result ' ^{14}C' works , but 'x^{y}_{z}' does not,
On Wed, Apr 17, 2013 at 10:18 PM, John Hendy jw.he...@gmail.com wrote:
On Wed, Apr 17, 2013 at 9:57 PM, Daniel Mahler dmah...@gmail.com wrote:
This works for me in org 7.9.2 and emacs 24.1.1, but chaining as in
'x^{y}_{z}' will only fontify the ^{y} but not the _{z}, as I reported
earlier today, but 'x^{y} _{z}' will fontify both, just with an ugly
gap in
the middle.
Ah. Googled around a bit. Are you sure you don't have something in
.emacs to set this? If not, perhaps the default settings just changed
since 7.9.2 and the current master branch, 8.0-pre. I found this upon
googling fontify subscripts orgmode:
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-10/msg00358.html
I added this to my buffer:
#+startup: entitiespretty
Now I get the attached. Indeed = ^{14}C= does not work for me, but
=x^{y}_{z}= does.
John
cheers
Daniel
On Tue, Apr 16, 2013 at 1:29 AM, Bastien b...@gnu.org wrote:
Hi Thomas,
t...@tsdye.com (Thomas S. Dye) writes:
With a recent git pull and #+OPTIONS: ^:{}, `C^{14}' is interpreted
correctly but ` ^{14}C' is not, both in the Org buffer and in LaTeX
export. The space before the caret appears to be the problem.
Confirmed -- this was reported already once. I don't have a fix for
this at the moment, hopefully Nicolas can have a look sometime.
--
Bastien
[O] [PATCH 1/4] Clean up various org-babel-*-maybe commands
* lisp/ob-core.el (org-babel-when-in-src-block): New macro. (org-babel-execute-src-block-maybe) (org-babel-expand-src-block-maybe) (org-babel-load-in-session-maybe, org-babel-pop-to-session-maybe): Use it. org-babel-get-src-block-info is a potentially expensive operation, which is why its ‘light’ argument exists. But in any case, it is overkill to query the whole info, if all that is needed is whether point is in a block or not. Factor the simplified common code out into a macro. --- lisp/ob-core.el | 34 -- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index b8d93f2..e44fc02 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -351,15 +351,25 @@ of potentially harmful code. (or (org-babel-execute-src-block-maybe) (org-babel-lob-execute-maybe))) +(defmacro org-babel-when-in-src-block (rest body) + Execute BODY if point is in a source block and return t. + +Otherwise do nothing and return nil. + `(if (or (org-babel-where-is-src-block-head) + (org-babel-get-inline-src-block-matches)) + (progn +,@body +t) + nil)) + (defun org-babel-execute-src-block-maybe () Conditionally execute a source block. Detect if this is context for a Babel src-block and if so then run `org-babel-execute-src-block'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info - (progn (org-babel-eval-wipe-error-buffer) - (org-babel-execute-src-block current-prefix-arg info) t) nil))) + (org-babel-when-in-src-block + (org-babel-eval-wipe-error-buffer) + (org-babel-execute-src-block current-prefix-arg))) ;;;###autoload (defun org-babel-view-src-block-info () @@ -395,10 +405,8 @@ a window into the `org-babel-get-src-block-info' function. Detect if this is context for a org-babel src-block and if so then run `org-babel-expand-src-block'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info - (progn (org-babel-expand-src-block current-prefix-arg info) t) - nil))) + (org-babel-when-in-src-block + (org-babel-expand-src-block current-prefix-arg))) ;;;###autoload (defun org-babel-load-in-session-maybe () @@ -406,10 +414,8 @@ then run `org-babel-expand-src-block'. Detect if this is context for a org-babel src-block and if so then run `org-babel-load-in-session'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info - (progn (org-babel-load-in-session current-prefix-arg info) t) - nil))) + (org-babel-when-in-src-block + (org-babel-load-in-session current-prefix-arg))) (add-hook 'org-metaup-hook 'org-babel-load-in-session-maybe) @@ -419,8 +425,8 @@ then run `org-babel-load-in-session'. Detect if this is context for a org-babel src-block and if so then run `org-babel-pop-to-session'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info (progn (org-babel-pop-to-session current-prefix-arg info) t) nil))) + (org-babel-when-in-src-block + (org-babel-switch-to-session current-prefix-arg))) (add-hook 'org-metadown-hook 'org-babel-pop-to-session-maybe) -- 1.8.2.1
Re: [O] [Bug] Removing scheduled/deadline shows Entry repeats:... which is not true
Hi Karl, Karl Voit devn...@karl-voit.at writes: Sorry for the late reply. This is because I do have troubles to come up with a minimal example. Starting Emacs with debug-init does not show this issue. I guess I have to strip down my config until this behavior changes (or add el-configs step by step). I'll report. Thanks. The bug looks pretty bad, so I hope this is just a problem in your configuration. But still, I hope this is not a problem in the way Org allows you to combine several options. -- Bastien
[O] [PATCH] bug in org-babel-execute-src-block
Hello, I’ve discovered a bug in org-babel-execute-src-block. Calls to setf can leak outside of the function and affect the library of babel. The attached org file illustrates the problem. The attached patch fixes it. * Bug Step 1: place the foo code block below into a different file and ingest that file into the library of babel. (It must be in a separate file for the bug to manifest.) #+name: foo #+BEGIN_SRC emacs-lisp 2 #+END_SRC Step 2: evaluate this code block. The result should be =(:results . replace)= #+BEGIN_SRC emacs-lisp :results append (assq :results (nth 2 (cdr (assq 'foo org-babel-library-of-babel #+END_SRC #+RESULTS: : (:results . replace) : (:results . silent) Step 3: evaluate this source block: #+BEGIN_SRC emacs-lisp :var bar=foo bar #+END_SRC #+RESULTS: : 2 Step 4: re-evaluate the block from step 2. The result should be =(:results . silent)= From 84531966dc5ca50fb56c61726694e988da3053eb Mon Sep 17 00:00:00 2001 From: Aaron Ecay aarone...@gmail.com Date: Thu, 18 Apr 2013 04:02:47 -0400 Subject: [PATCH 4/4] Fix bug in org-babel-execute-src-block * lisp/ob-core.el (org-babel-execute-src-block): copy the info Otherwise, the setf calls in this function can reach into and change other configuration variables, such as the library of babel. --- lisp/ob-core.el | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 12fcecc..71e9d61 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -547,7 +547,9 @@ Optionally supply a value for PARAMS which will be merged with the header arguments specified at the front of the source code block. (interactive) - (let* ((info (or info (org-babel-get-src-block-info))) + (let* ((info (if info + (copy-tree info) + (org-babel-get-src-block-info))) (merged-params (org-babel-merge-params (nth 2 info) params))) (when (org-babel-check-evaluate (let ((i info)) (setf (nth 2 i) merged-params) i)) -- 1.8.2.1 -- Aaron Ecay
Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate
Hi Eric,
2013ko apirilak 2an, Eric Schulte-ek idatzi zuen:
I'm happy to apply this patch, however please also supply a patch which
updates the corresponding documentation.
By “documentation” you mean the texinfo manual, right? Here is a new
version of this patch which also updates the manual.
From 62ea51f473d387137b5294705241795d1d8bc39b Mon Sep 17 00:00:00 2001
From: Aaron Ecay aarone...@gmail.com
Date: Sun, 31 Mar 2013 18:47:44 -0400
Subject: [PATCH] Add 'inline-only option to org-export-babel-evaluate
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* lisp/ob-exp.el (org-export-babel-evaluate): Update defcustom to
provide 'inline-only option
(org-babel-exp-results): Implement 'inline-only for
org-export-babel-evaluate
* doc/org.texi (Exporting code blocks): Document ‘inline-only setting
for org-export-babel-evaluate
This is useful because there is no way for inline results to be stored.
The imagined usecase is that all non-inline source blocks will be
evaluated manually by the user. Inline blocks, however, must be
evaluated during export, or they will be simply deleted by the exporter.
---
doc/org.texi | 7 ++-
lisp/ob-exp.el | 11 ---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index b4a9d8f..f8f9c31 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -12928,7 +12928,12 @@ Setting the @code{org-export-babel-evaluate} variable to @code{nil} will
ensure that no code blocks are evaluated as part of the export process. This
can be useful in situations where potentially untrusted Org mode files are
exported in an automated fashion, for example when Org mode is used as the
-markup language for a wiki.
+markup language for a wiki. It is also possible to set this variable to
+@code{‘inline-only}. In that case, only inline code blocks will be
+evaluated, in order to insert their results. Non-inline code blocks are
+assumed to have their results already inserted in the buffer by manual
+evaluation. This setting is useful to avoid expensive recalculations during
+export, not to provide security.
@comment node-name, next, previous, up
@comment Extracting source code, Evaluating code blocks, Exporting code blocks, Working With Source Code
diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index e74b803..aa496d3 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -52,10 +52,13 @@
(defcustom org-export-babel-evaluate t
Switch controlling code evaluation during export.
When set to nil no code will be evaluated as part of the export
-process.
+process. When set to 'inline-only, only inline code blocks will
+be executed.
:group 'org-babel
:version 24.1
- :type 'boolean)
+ :type '(choice (const :tag Never nil)
+ (const :tag Only inline code inline-only)
+ (const :tag Always t)))
(put 'org-export-babel-evaluate 'safe-local-variable (lambda (x) (eq x nil)))
(defun org-babel-exp-get-export-buffer ()
@@ -378,7 +381,9 @@ Results are prepared in a manner suitable for export by org-mode.
This function is called by `org-babel-exp-do-export'. The code
block will be evaluated. Optional argument SILENT can be used to
inhibit insertion of results into the buffer.
- (when (and org-export-babel-evaluate
+ (when (and (or (eq org-export-babel-evaluate t)
+ (and (eq type 'inline)
+ (eq org-export-babel-evaluate 'inline-only)))
(not (and hash (equal hash (org-babel-current-result-hash)
(let ((lang (nth 0 info))
(body (if (org-babel-noweb-p (nth 2 info) :eval)
--
1.8.2.1
Thanks,
--
Aaron Ecay
Re: [O] [PATCH 0/3] synctex support for pdf export
Hi Nicolas, 2013ko apirilak 4an, Nicolas Goaziou-ek idatzi zuen: I don't think there is a complete solution to this problem. Though `org-export-before-processing-hook' allows to work on an exact copy of the buffer being exported before any file is included and any Babel block executed. You can add text properties there. And with `org-export-before-parsing-hook', you can check what parts of the buffer are new (generated from include keywords, macros and blocks). From there it may be possible to implement a lookup function which would find the appropriate line in the original buffer. Thanks for your advice. I haven’t had time to work more on these patches, but I do think I see a way forward. Hopefully I (or somebody else!) will have some time soon to devote to the problem. Thanks, -- Aaron Ecay
Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate
Hi Aaron, I applied this patch, thanks a lot. Please see the small changes I made to the ChangeLog entry for next commit messages: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=25869e Sorry, I know this sounds nitpicking and perhaps pedantic, but the more careful we are about this upstream, the less pain it is for the one who merges Org into Emacs... Thanks! -- Bastien
Re: [O] [PATCH] bug in org-babel-execute-src-block
Hi Aaron, Aaron Ecay aarone...@gmail.com writes: From 84531966dc5ca50fb56c61726694e988da3053eb Mon Sep 17 00:00:00 2001 From: Aaron Ecay aarone...@gmail.com Date: Thu, 18 Apr 2013 04:02:47 -0400 Subject: [PATCH 4/4] Fix bug in org-babel-execute-src-block Applied, thanks. -- Bastien
Re: [O] [Bug] Removing scheduled/deadline shows Entry repeats:... which is not true
* Bastien b...@gnu.org wrote: Hi Karl, Karl Voit devn...@karl-voit.at writes: Sorry for the late reply. This is because I do have troubles to come up with a minimal example. Starting Emacs with debug-init does not show this issue. I guess I have to strip down my config until this behavior changes (or add el-configs step by step). I'll report. Thanks. The bug looks pretty bad, so I hope this is just a problem in your configuration. But still, I hope this is not a problem in the way Org allows you to combine several options. I'm a bit puzzled since this issue seem to have disappeared. Yesterday, I was facing this message but today (without upgrading Org-mode!) I can not reproduce it either :-O Let's say it was something deeply related to my config which changed meanwhile. Sorry for the fuzz. -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: get Memacs from https://github.com/novoid/Memacs https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate
Hello, Bastien wrote: I applied this patch, thanks a lot. Please see the small changes I made to the ChangeLog entry for next commit messages: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=25869e How is that suppose to cooperate with :eval never-export (which avoids all the evaluations during export)? I'm not sure to understand why this change is implemented as a variable which we would have to set up in our .emacs or bind in the file, instead of an header argument which we could set wherever we want (system-wide, language-specific, buffer-wide, subtree-wide, or code block-specific)... Best regards, Seb -- Sebastien Vauban
Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate
Hi Sebastien, 2013ko apirilak 18an, Sebastien Vauban-ek idatzi zuen: Hello, Bastien wrote: I applied this patch, thanks a lot. Please see the small changes I made to the ChangeLog entry for next commit messages: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=25869e How is that suppose to cooperate with :eval never-export (which avoids all the evaluations during export)? I could be wrong, but I don’t seem to see a convenient way to set this header arg for both inline source blocks and #+call lines. These both have no way of storing their results in a buffer, so in order to have them be present in the export they must be evaluated every time. On the other hand, it is not always desirable to call code blocks on every export. They could be very time-consuming to compute. So, a way to pick out the non-results-storing blocks is needed. I'm not sure to understand why this change is implemented as a variable which we would have to set up in our .emacs or bind in the file, instead of an header argument which we could set wherever we want (system-wide, language-specific, buffer-wide, subtree-wide, or code block-specific)... What form would this take? Would we have a value of :eval which is never-export-unless-inline? -- Aaron Ecay
Re: [O] [PATCH] Add 'inline-only option to org-export-babel-evaluate
Hi Aaron, Aaron Ecay wrote: 2013ko apirilak 18an, Sebastien Vauban-ek idatzi zuen: Bastien wrote: I applied this patch, thanks a lot. Please see the small changes I made to the ChangeLog entry for next commit messages: http://orgmode.org/cgit.cgi/org-mode.git/commit/?id=25869e How is that suppose to cooperate with :eval never-export (which avoids all the evaluations during export)? I could be wrong, but I don’t seem to see a convenient way to set this header arg for both inline source blocks and #+call lines. These both have no way of storing their results in a buffer, so in order to have them be present in the export they must be evaluated every time. On the other hand, it is not always desirable to call code blocks on every export. They could be very time-consuming to compute. So, a way to pick out the non-results-storing blocks is needed. I'm not sure to understand why this change is implemented as a variable which we would have to set up in our .emacs or bind in the file, instead of an header argument which we could set wherever we want (system-wide, language-specific, buffer-wide, subtree-wide, or code block-specific)... What form would this take? Would we have a value of :eval which is never-export-unless-inline? As we're talking of evaluation, and as there is already an :eval header argument (with lots of options), I think it'd better to try to add your requirement as a new option, yes, instead of having complex rules for knowing what happens depending on every option of :eval times 2 (with or without your new value). I'm not sure what :eval never-export currently does with inline blocks, but (depending on that) I'd rather add the new value never-export-except-inline (or never-export-nor-inline). Note -- The option names are not correct, just to carry what I mean... That way, you can impose your new behavior wherever you want, as well in parts of your Org document. Best regards, Seb -- Sebastien Vauban
Re: [O] Date-tree capture confused when nearby trees have dates
Hi Suvayu, Suvayu Ali fatkasuvayu+li...@gmail.com writes: Capture gets confused and cannot find the real date-tree if there are nearby trees with headlines like this: ** 2013 June - Event 2 ** 2013 March - Event 1 Fixed, thanks. Note that you can still use tags in a datetree. So ** 2013 and ** 2013 :noexport: are equivalent. Thanks for reporting this! -- Bastien
Re: [O] uniborg
Jay Kerns gjkerns...@gmail.com writes: I remember reading a discussion some time ago about Org, and the Borg, and unicorns with mechanical faceplates, Resistance is futile, etc. Here is one interpretation of a uniborg: http://orgmode.org/worg/org-artwork.html :) Also, I uploaded the SVG version of the new logo, it's under CC by-sa if people want to use/modify it: http://orgmode.org/img/org-mode-unicorn-logo.svg -- Bastien
Re: [O] some key sequence transform my text in outline
Luca Ferrari fluca1...@infinito.it writes: Apparently I found the sequence that lead to the problem: I opened a #+begin_src on a line and then pressed TAB on such line. This folded the following text until a new #+end_src is found, masking whole sections. The problem is that this is no more able to be expanded. However, editing the text file externally and removing some text after the #+begin_src (in particular a table) solved the problem. I'm investigating more... It would be really nice to have a command to check that no #+begin_src contains a headline, as this can confuse visibility cycling a lot, among other things. -- Bastien
Re: [O] agenda: personal priority for today
Hi Daniel, You can now use M-up and M-down to move agenda lines around. This is for quick use only. It is not persistent and the agenda will be reordered on next refresh. -- Bastien
Re: [O] [PATCH 1/4] Clean up various org-babel-*-maybe commands
Aaron Ecay aarone...@gmail.com writes: * lisp/ob-core.el (org-babel-when-in-src-block): New macro. (org-babel-execute-src-block-maybe) (org-babel-expand-src-block-maybe) (org-babel-load-in-session-maybe, org-babel-pop-to-session-maybe): Use it. Applied, thanks. -- Bastien
Re: [O] Date-tree capture confused when nearby trees have dates
On Thu, Apr 18, 2013 at 12:21:42PM +0200, Bastien wrote: Suvayu Ali fatkasuvayu+li...@gmail.com writes: Capture gets confused and cannot find the real date-tree if there are nearby trees with headlines like this: ** 2013 June - Event 2 ** 2013 March - Event 1 Fixed, thanks. I can confirm the problem is gone. :) Note that you can still use tags in a datetree. So ** 2013 and ** 2013 :noexport: are equivalent. I can't think when I would use it, but I'll keep that in mind. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Date-tree capture confused when nearby trees have dates
Suvayu Ali fatkasuvayu+li...@gmail.com writes: I can't think when I would use it, but I'll keep that in mind. Yep, I added a footnote for this in the manual. -- Bastien
Re: [O] Logbook drawer entries make editing very slow
Hi Marcel, Marcel van der Boom mar...@hsdev.com writes: I'm using habit-style items a lot in my 'org' routine. A typical entry would look like this: #+BEGIN_SRC org *** TODO Do something daily SCHEDULED: 2013-02-20 wo .+1d :LOGBOOK: - State DONE from TODO [2013-02-19 di 14:01] - State DONE from TODO [2013-02-17 zo 12:39] ... [lots of entries here] ... - State DONE from TODO [2010-02-25 Thu 13:51] - State DONE from TODO [2010-02-10 Wed 15:19] :END: :PROPERTIES: :STYLE: habit :LAST_REPEAT: [2013-02-19 di 14:01] :CREATED: 2011-03-25 vr 12:33 :END: ...Some description... #+END I have all habits in a file habits.org which is part of the 'org-agenda-files' list. When editing entries in the habits.org file, for example changing the header, emacs CPU using goes to 100% and every keystroke takes 5-10 seconds. (org-at-item-p) can be very expensive, because it calls (org-list-in-valid-context-p) which is also expensive and clearly not optimized for every list movements. I found out that the use is still acceptable for 1000-2000 list items, so I won't fix this right now, but something to keep under the radar, yes. In the meantime, cleaning out the logs sometimes is the only suggestion I can make. Thanks for reporting this, -- Bastien
Re: [O] org-exp-bibtex missing in git?
Hi Aaron, Aaron Ecay aarone...@gmail.com writes: I hope this is not bothersome ... it is not, heads up are always welcome. but have you had a chance to look at these patches? No -- and we are close to the release now, so let's not introduce new syntax for this. We still need to discuss this after Org 8.0, as the functionality is indeed needed. Feel free to raise it again then! And thanks for those patches. -- Bastien
Re: [O] uniborg
On Thu, Apr 18, 2013 at 6:22 AM, Bastien b...@gnu.org wrote: [snip] Also, I uploaded the SVG version of the new logo, it's under CC by-sa if people want to use/modify it: http://orgmode.org/img/org-mode-unicorn-logo.svg Thanks - looks great. I still get the same 404 Not Found on uniborg.svg, but I wouldn't classify that as mission-critical. -- Jay
[O] ox missed by make clean-install
Hi all, I just noticed that ox-* files are not removed by 'make clean-install' for me. Is this intended/my setup/a bug? - Andreas
Re: [O] ox missed by make clean-install
Hi Andreas, Andreas Leha andreas.l...@med.uni-goettingen.de writes: I just noticed that ox-* files are not removed by 'make clean-install' for me. Is this intended/my setup/a bug? No, just something we overlooked. Fixed now, thanks for reporting it! -- Bastien
Re: [O] agenda: personal priority for today
You can now use M-up and M-down to move agenda lines around. This is for quick use only. It is not persistent and the agenda will be reordered on next refresh. That's nice, thanks.
Re: [O] Spreadsheet calculations (24.3/8.0-pre)
Hi Oliver, Oliver Večerník o...@vecernik.at writes: Hi Ippei, | Product |g | kJ/100g | kJ | kcal | |---+--+-+--+--| | Bread | 50.6 |1372 | 694 | 166 | | Butter| 11.5 |3054 | 351 | 84 | | Marmalade | 19.7 | 926 | 182 | 44 | |---+--+-+--+--| | | | | 1227 | 294 | #+TBLFM: $3='(org-lookup-first $1 '(remote(nf,@I$1..@II$1)) (remote(nf,@I$2..@II$2))) #+TBLFM: $4='(* $2 (/ $3 $b));N%.0f #+TBLFM: $5=$4/$j;%.0f #+TBLFM: @$4..$5=vsum(@I..II) (Each TBLFM line has no linebreak.) thanks for your suggestion, but I didn't want an extra column. I played with `N' and `L' options and found following solution leaving them out entirely: #+TITLE: Nutrition Facts #+CONSTANTS: b=100.0 j=4.184 #+TBLNAME: nf | Product | kJ | kcal | |-+--+--| | Bread white | 1372 | 328 | | Butter | 3054 | 730 | | Marmalade | 926 | 221 | #+TBLFM: $3=$2/$j;%.0f | Product |g | kJ | kcal | |-+--+--+--| | Bread white | 50.6 | 694 | 166 | | Butter | 11.5 | 351 | 84 | | Marmalade | 19.7 | 182 | 43 | | nonexistent | |0 |0 | |-+--+--+--| | | | 1227 | 293 | #+TBLFM: $3='(* (string-to-number $2) (/ (string-to-number (org-lookup-last $1 '(remote(nf,@I$1..@II$1)) '(remote(nf,@I$2..@II$2 $b));%.0f::$4=$3/$j;%.0f::@$3..$4=vsum(@I..II) $1 has to be a string, because the lookup column can have more than one word. For the math I have to convert the strings to numbers. Maybe someone has an idea for a more elegant solution, but this works for me now. I confirm there is no other elegant solution that either using an additional column or using the internal conversion you used. -- Bastien
[O] Using helm only for org refiling
Hello, I tried using helm (the successor to anything) for everything, and it was a bit too much. However, I really appreciated how it integrated with org refiling. I've been trying to figure out how to enable helm only for refiling, by binding C-c C-w in the org-mode-map to something, but I'm getting lost in helm's source code. I guess it's calling helm-org-headlines at some point, but I cannot find how it interacts with the usual refiling approach. If someone is using helm with refiling, I'd gladly use some help here. Thanks, Alan
Re: [O] [PATCH 0/3] synctex support for pdf export
Aaron Ecay aarone...@gmail.com writes: 2013ko apirilak 4an, Nicolas Goaziou-ek idatzi zuen: I don't think there is a complete solution to this problem. Though `org-export-before-processing-hook' allows to work on an exact copy of the buffer being exported before any file is included and any Babel block executed. You can add text properties there. And with `org-export-before-parsing-hook', you can check what parts of the buffer are new (generated from include keywords, macros and blocks). From there it may be possible to implement a lookup function which would find the appropriate line in the original buffer. Thanks for your advice. I haven’t had time to work more on these patches, but I do think I see a way forward. Hopefully I (or somebody else!) will have some time soon to devote to the problem. I would be interested in a SyncTeX-based solution. Thanks for your work on this, Aaron. –Rasmus -- Vote for proprietary math!
[O] Release 8.0
Dear all, I'm releasing Org 8.0. See the release notes below or at http://orgmode.org/Changes.html This release is potentially the most disruptive release since long, so please don't use it in production before you can carefully review the release notes and update your configuration -- especially with respect to export features. I would like to thank you all again for your patience, and special thanks to Nicolas who is just great to work with. I'm happy to see his code finally widely available for all Org users, not just the happy few. Enjoy! ORG 8.0 Installation Installation instructions have been updated and simplified. If you have troubles installing or updating Org, focus on these instructions: • when updating via a `.zip/.tar.gz' file, you only need to set the `load-path' in your `.emacs'. Set it before any other Org customization that would call autoloaded Org functions. • when updating by pulling Org's Git repository, make sure to create the correct autoloads. You can do this by running `~$ make autoloads' (to only create the autoloads) or by running `~$ make' (to also compile the Emacs lisp files.) `~$ make help' and `~$ make helpall' gives you detailed explanations. • when updating through ELPA (either from GNU ELPA or from Org ELPA), you have to install Org's ELPA package in a session where no Org function has been called already. When in doubt, run `M-x org-version RET' and see if you have a mixed-up installation. See [http://orgmode.org/org.html#Installation] for details. Incompatible changes Org 8.0 is the most disruptive major version of Org. If you configured export options, you will have to update some of them. If you used `#+ATTR_*' keywords, the syntax of the attributes changed and you will have to update them. Below is a list of changes for which you need to take action. See [http://orgmode.org/worg/org-8.0.html] for the most recent version of this list and for detailed instructions on how to migrate. New export engine ╌ Org 8.0 comes with a new export engine written by Nicolas Goaziou. This export engine relies on `org-element.el' (Org's syntax parser), which was already in Org's core. This new export engine triggered the rewriting of /all/ export back-ends. The most visible change is the export dispatcher, accessible through the keybinding `C-c C-e'. By default, this menu only shows some of the built-in export formats, but you can add more formats by loading them directly (e.g., `(require 'ox-texinfo)' or by configuring the option org-export-backends. More contributed back-ends are available from the `contrib/' directory, the corresponding files start with the `ox-' prefix. If you customized an export back-end (like HTML or LaTeX), you will need to rename some options so that your customization is not lost. Typically, an option starting with `org-export-html-' is now named `org-html-'. See the manual for details and check [this Worg page] for directions. [this Worg page] http://orgmode.org/worg/org-8.0.html New syntax for #+ATTR_HTML/LaTeX/… options ╌╌ ╭ │ #+ATTR_HTML width=200px ╰ should now be written ╭ │ #+ATTR_HTML :width 200px ╰ Keywords like `#+ATTR_HTML' and `#+ATTR_LaTeX' are defined in their respective back-ends, and the list of supported parameters depends on each backend. See Org's manual for details. `org-remember.el' has been removed ╌╌ You cannot use `remember.el' anymore to capture notes. Support for remember templates has been obsoleted since long, it is now fully removed. Use `M-x org-capture-import-remember-templates RET' to import your remember templates into capture templates. `org-jsinfo.el' has been merged into `ox-html.el' ╌ If you were requiring `ox-jsinfo.el' in your `.emacs.el' file, you will have to remove this requirement from your initialization file. Note for third-party developers ╌╌╌ The name of the files for export back-end have changed: we now use the prefix `ox-' for those files (like we use the `ob-' prefix for Babel files.) For example `org-html.el' is now `ox-html.el'. If your code relies on these files, please update the names in your code. Packages moved from core to contrib ╌╌╌ Since packages in Org's core are meant to be part of GNU Emacs, we try to be minimalist when it comes to adding files into core. For 8.0, we moved some contributions into the `contrib/' directory. The rationale for deciding that these files should live in `contrib/' is either because they rely on
Re: [O] OT: Android, external HW-keyboard and Emacs (was: Org-mode as a replacement for Google Reader)
Android emacs has known problems segfaulting dependant on font size. Try starting with the smallest font work your way up. See: https://github.com/zielmicha/emacs-android/issues/2 for further information workarounds On Tue, Apr 16, 2013 at 6:21 AM, Karl Voit devn...@karl-voit.at wrote: * Tom t...@goochesa.de wrote: Karl Voit devn...@karl-voit.at schrieb: I also tested a FreedomPro bluetooth keyboard with my XOOM tablet. Unfortunately, no Ctrl/ESC/Alt is working. So Android/Emacs is not usable without the Hacker's keyboard which is an on-screen keyboard that offers all those modifier keys. When the on-screen keyboard uses half of the tablet screen, it is no fun using Emacs at all. There is an app, External Keyboard Helper (Pro), that enables full usage of most bluetooth/usb keyboards. It is not without usability Problems, some would need a rooted phone to solve, but I'm happy with the setup so far. I mostly need it for connectbot sessions. Thank you *very* much for this pointer! Unfortunately, my Android Emacs segfaults now (can't test it) and while typing in a note taking app works quite fine, simple characters like «!» do not work in ConnectBot/vim :-( I have to invest some time in this tool. Probably I might be able to get it to work. -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: get Memacs from https://github.com/novoid/Memacs https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github -- Subhan Michael Tindall | Software Developer | s...@rentrakmail.com RENTRAK | www.rentrak.com | NASDAQ: RENT
[O] New maintainer
Dear all, I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) -- Bastien
Re: [O] Best practices for literate programming [was: Latex export of tables]
Thomas, Tom, do tell us more about what these habits are. The new exporter is really your friend. Where before I might choose to generate a LaTeX block, now I look to generate Org output and then count on the exporter to do the right thing on the way to pdf. The exporter's attribute system is very easy to use. The attributes you need to access are always right there. I've also come to rely on filters quite a bit. I use them for non-breaking spaces, the plus/minus symbol, and for the multiple citation commands used by biblatex (e.g., \parencites). There seems to be a move afoot to collect filters so they can be widely distributed. I'd like to see the filters go to the Library of Babel, but for reproducible research it is probably best to keep them with the source document so there is no doubt about the fidelity of filter code. I too rely heavily on filters and customizations. I haven't been able to fully appreciate the asynchronous exporter yet. For instance I set some defaults for tables, pictures, add lots of entities etc. in my init file, and I went as far as writing a separate init file just loading just the org stuff. Now, this is clearly /not/ a very reproducible way of doing this. So I'm really interested in hearing or seeing implementation where the goal is reproducibility. On one hand I can appreciate keeping Org close to a vanilla state. On the other hand, I'd have to overwrite defaults every time (e.g. I /always/ want booktab tables). I guess I could keep an emacs-lisp block in the top of the file specifying stuff, but it also seems kind of tedious (copy-pasting every time). (Perhaps this could be resolved by loading external files hosted somewhere accessible). –Rasmus -- . . . The proofs are technical in nature and provides no real understanding.
Re: [O] Release 8.0
Bastien Could you please correct the headers to ox-html.el and ox-odt.el. I have not assigned the rights to my changes to FSF. These files - due to Emacs project policy - cannot be part of Emacs. Jambunathan K.
Re: [O] New maintainer
Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. To the new maintainer, My changes to ox-html.el and ox-odt.el are not assigned to FSF. So please correct the headers of these file to reflect the reality. Also be respectful of my wish and refrain from merging my changes to Emacs. It is a polite request. Write to me if you have questions. Jambunathan K.
Re: [O] New maintainer
Bastien b...@gnu.org writes: I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! A huge thumbs up from this extremely grateful user! And an equally huge thank you, Bastien, for shouldering the burden of maintainership, for the diligence with which you have handled the task (and the hundreds/thousands of emails which have kept the project moving) and maybe above all for your patience and steadfastness under totally unmerited fire. with all good wishes Glyn
Re: [O] Release 8.0
Hi Jambunathan, Jambunathan K kjambunat...@gmail.com writes: Could you please correct the headers to ox-html.el and ox-odt.el. I corrected the header for ox-html.el: the header said you were the only author while it's clear half of the code was simply copied from Carsten. I added Carsten as the author. I have not assigned the rights to my changes to FSF. These files - due to Emacs project policy - cannot be part of Emacs. RMS confirmed that you changes were assigned in a private email that we both received this morning. It's your right to disagree, but first solve this dispute with the FSF before asking me to obey to you. I'm following the advice of the FSF for now. -- Bastien
Re: [O] Release 8.0
Bastien b...@gnu.org writes: I'm releasing Org 8.0. Fantastic work. Warm congratulations to all those involved! François
Re: [O] Best practices for literate programming [was: Latex export of tables]
Hi Rasmus, 2013ko apirilak 18an, Rasmus-ek idatzi zuen: I too rely heavily on filters and customizations. I haven't been able to fully appreciate the asynchronous exporter yet. For instance I set some defaults for tables, pictures, add lots of entities etc. in my init file, and I went as far as writing a separate init file just loading just the org stuff. Now, this is clearly /not/ a very reproducible way of doing this. So I'm really interested in hearing or seeing implementation where the goal is reproducibility. On one hand I can appreciate keeping Org close to a vanilla state. On the other hand, I'd have to overwrite defaults every time (e.g. I /always/ want booktab tables). I guess I could keep an emacs-lisp block in the top of the file specifying stuff, but it also seems kind of tedious (copy-pasting every time). (Perhaps this could be resolved by loading external files hosted somewhere accessible). If your external org configuration file were kept under version control (I’ll discuss git but the principle is general), then reproducibility would be possible. There are ways of embedding git hashes in LaTeX documents (for one example: http://thorehusfeldt.net/2011/05/13/including-git-revision-identifiers-in-latex/), and of course org could help automate this. Including the git hash of the document itself, the config file, and org-mode’s own code (assuming these are kept in 3 separate repos) should allow perfect reproducibility (modulo incompatible changes in emacs, I guess). It would be interesting for org to have an ability to reference files not just by name, but by git revision. So that you could do something like (where 123456 is some git hash): #+include: [[gitbare:/path/to/repo::123456:my-org-setup-file.org]] and have org take care of checking out the proper revision and loading the file in the usual way. This syntax is already implemented, for plain links, in contrib/lisp/org-git-link.el, so it is just a matter of making #+include and friends understand links in addition to filenames. -- Aaron Ecay
Re: [O] Release 8.0
On Thu, Apr 18, 2013 at 11:41 AM, Bastien b...@gnu.org wrote: Dear all, I'm releasing Org 8.0. Simply fantastic. Many thanks and great work on such a detailed list of changes. Just mind-blowing how awesome this project is. Thanks to all the contributors for this great piece of software -- I use it everyday with outstanding benefits compared to not having it. John
Re: [O] Release 8.0
Neuwirth Erich writes: I compiled from the repository after the announcement. On my Mac (OSX 10.8.3, Emacs 24.3.1) the test for maxima still fail. I reported this a few weeks ago. I can't find any post from you on this mailing list that fits that description and your last post mentioning maxima is from March last year. Ran 443 tests, 436 results as expected, 7 unexpected (2013-04-18 19:38:30+0200) 5 expected failures 7 unexpected results: FAILED ob-maxima/integer-input FAILED ob-maxima/list-input FAILED ob-maxima/matrix-output FAILED ob-maxima/simple-list-input FAILED ob-maxima/string-input FAILED ob-maxima/table-input1 FAILED ob-maxima/table-input2 make[1]: *** [test-dirty] Error 1 Well this looks like all maxima tests have failed, so you might want to check if it's correctly configured on your system and/or if there's some extra definition you'll have to give so that the test will find it (it runs from 'emacs -Q', so you'll have to add any extra setup to the config variables that make uses). Also, please trim your quotes. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada
Re: [O] Release 8.0
I added Carsten as the author. I have no problem with that. You can even add N other authors as long as my name stays there. I'm following the advice of the FSF for now. FSF position is ambivalent. They have made a decision (to suit their convenience) and shifting the burden on me. Their response is simply not consistent with Emacs project policy or the most ethical one. Both FSF and you [1] are robbing Peter and paying Paul. For the serious observers, I have posted a response here. http://lwn.net/Articles/547737/ I also cite the specific term of my future assignment based on which I claim that I have the right to report on changes that is not covered by contract. [1] You didn't take my permission to move the files from contrib/lisp to lisp. Jambunathan K.
Re: [O] New maintainer
On Thu, Apr 18, 2013 at 12:10 PM, Jambunathan K kjambunat...@gmail.com wrote: Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. To the new maintainer, My changes to ox-html.el and ox-odt.el are not assigned to FSF. So please correct the headers of these file to reflect the reality. Also be respectful of my wish and refrain from merging my changes to Emacs. It is a polite request. Write to me if you have questions. I'd like some definitive resolution to this issue or list-wide understanding of where things are at. I've been trying to follow your saga, and my understanding is: - You signed over contribution rights to FSF at one point. Is this correct? - You have contacted FSF (or Emacs?) and requested that these rights be revoked/reversed? - Has the FSF (or Emacs?) provided any statement/ruling on whether or not they will honor your request? I hear you, and you definitely make it known that you would like to undo what you once did... but my perception is that your emails speak as though there is no agreement in place at all... but you *did* sign the contract at one point, right? I've not contributed to code, so I've never seen the FSF papers and don't really know what they entail... but if they are signing away rights to future contributions, it would seem that your work is under that umbrella until *they* provide confirmation that the umbrella no longer exists (*and* no longer exists retroactively). Just trying to reconcile my understanding of your situation with how you write about it. Thanks, John Jambunathan K.
Re: [O] Release 8.0
François Pinard pin...@iro.umontreal.ca writes: Bastien b...@gnu.org writes: I'm releasing Org 8.0. Fantastic work. Warm congratulations to all those involved! Seconded!! The new exporter is terrific :-) atb Glyn
Re: [O] Release 8.0
Excellent news! Thanks to you Bastien and to all the other people who have helped make this possible. -- Aaron Ecay
Re: [O] Release 8.0
Aaron Ecay aarone...@gmail.com writes: Excellent news! Thanks to you Bastien and to all the other people who have helped make this possible. You speak as though other people don't exist or matter. IMO, you are doing a disservice to other contributors by *not* naming them. Is it really difficult for you to read the soruce code or changelog and educate yourself on who these other people are. Please name the people who are thanking. It's just basic courtesy. Stop saying other people and all contributors. Jambunathan K.
Re: [O] Release 8.0
Bastien b...@gnu.org writes: I would like to thank you all again for your patience, and special thanks to Nicolas who is just great to work with. I'm happy to see his code finally widely available for all Org users, not just the happy few. I would also like to thank Nicolas for this impressive archivement! Thanks a lot! It is much appreciated! ORG 8.0 Congrats Bastien! It's looks like a nice release (and indeed based on the git version it is!) –Rasmus -- When the facts change, I change my mind. What do you do, sir?
Re: [O] New maintainer
Please let's not reopen this issue. Jambunathan signed the FSF copyright assignment for his past and future changes to Emacs code. He claims that he can retract this assignment for changes he made against some Emacs files. FSF says this is not possible. And it does not take too big a brain to understand why: if people were allowed to retract their assignment when they want for changes that have been published, the copyright assignment process would undermine the whole purpose of the GPL license, which is to make it possible to let *others* contribute to free code. If there were a problem, it would be a problem for Emacs, not for upstream Org-mode, which can include any GPL code. But there is no problem. Just someone upset, in bad need for a ban. -- Bastien
Re: [O] New maintainer
The king is dead, long live the king! :-) Thank you, Bastien, for all the work! And thank you, Carsten, for all the work to come! Detlef On Thu, 18 Apr 2013 18:53:32 +0200 Bastien b...@gnu.org wrote: Dear all, I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) -- Bastien
Re: [O] New maintainer
Hi Bastien, 2013ko apirilak 18an, Bastien-ek idatzi zuen: [...] I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! Just as Batman and Robin are often seen together, I hope you’ll continue to be a presence in the org community. I always appreciate the helpfulness and patience that you embody. Thanks, -- Aaron Ecay
Re: [O] Release 8.0
Jambunathan K kjambunat...@gmail.com writes: You speak as though other people don't exist or matter. IMO, you are doing a disservice to other contributors by *not* naming them. All contributors, including you, have been thanked in the release notes I attached with the original announcement. We don't want everybody to copy-past this section in their reply :) -- Bastien
Re: [O] New maintainer
Rasmus ras...@gmx.us writes: I expect you will still be around the mailing list, no? I'll focus on something else, but I'll stick around for sure, at least to ask questions and report bugs! -- Bastien
Re: [O] Release 8.0
François Pinard pin...@iro.umontreal.ca writes: Fantastic work. Warm congratulations to all those involved! You are a regular. Is it really difficult for you to spell out the names explicitly? All those involved is politically correct but it is a disservice to few individuals whose efforts have been nothing short of Herculean. Jambunathan K.
Re: [O] Best practices for literate programming [was: Latex export of tables]
Aaron Ecay aarone...@gmail.com writes: If your external org configuration file were kept under version control (I’ll discuss git but the principle is general), then reproducibility would be possible. There are ways of embedding git hashes in LaTeX documents (for one example: http://thorehusfeldt.net/2011/05/13/including-git-revision-identifiers-in-latex/), and of course org could help automate this. Including the git hash of the document itself, the config file, and org-mode’s own code (assuming these are kept in 3 separate repos) should allow perfect reproducibility (modulo incompatible changes in emacs, I guess). Sounds interesting. I'll check it out. It would be interesting for org to have an ability to reference files not just by name, but by git revision. So that you could do something like (where 123456 is some git hash): #+include: [[gitbare:/path/to/repo::123456:my-org-setup-file.org]] and have org take care of checking out the proper revision and loading the file in the usual way. This syntax is already implemented, for plain links, in contrib/lisp/org-git-link.el, so it is just a matter of making #+include and friends understand links in addition to filenames. Now that is a great idea that allows for both incremental improvements while still retaining compatibility for old files. –Rasmus -- And let me remind you also that moderation in the pursuit of justice is no virtue
Re: [O] New maintainer
Bastien b...@gnu.org writes: Please raise your thumbs up or your concerns, if any. Bastien, your maintainership has been just outstanding, so far that I could judge. You're among the great maintainers I happened to meet, and I tremendously enjoyed your way of driving the project. Let me thank you for it all. I wish Carsten will get, from all of us — OK! given a proper email kill file :-) — the same level of good will, enthusiasm and collaboration we have seen on this user group all along for the recent year. François
Re: [O] New maintainer
Bastien b...@gnu.org writes: And it does not take too big a brain to understand why: if people were allowed to retract their assignment when they want for changes that have been published, the copyright assignment process would undermine the whole purpose of the GPL license, which is to make it possible to let *others* contribute to free code. As a maintainer of GNU project, I expect that you should have a basic understanding of the purpose of the copyright assignment and GPL license. From what I read above, I am not convinced that you have the right understanding. Your articulation is clearly confusing and falling short. See http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright You assign copyright to FSF so that you don't have to enforce GPL. By assigning, one outsources the legal work of actual enforcing to FSF. Single holder of rights just makes the legal procedures lot more easy. A contract that cannot be enforced is worthless. A license that you cannot enforce is equally so. FSF says, assign me the rights, I will go after all the violators and force them to comply with GPL. Jambunathan K.
Re: [O] New maintainer
Just trying to reconcile my understanding of your situation with how you write about it. This post (not by me) summarizes my position well. http://lists.gnu.org/archive/html/emacs-devel/2013-04/msg00096.html I have also criticized FSF's arbitrary handling of my request here. http://lwn.net/Articles/547737/ If you move over to emacs-devel, you will see some of the commenters there are very guarded in their response. It will only go on to show that I raise valid questions. People who have flamed me cannot differentiate between oranges and lemons. It is not their work that is at stake. So they can just call me a troll and dismiss the broader questions I am raising. Jambunathan K.
Re: [O] Release 8.0
Bastien b...@gnu.org writes: Jambunathan K kjambunat...@gmail.com writes: You speak as though other people don't exist or matter. IMO, you are doing a disservice to other contributors by *not* naming them. All contributors, including you, have been thanked in the release notes I attached with the original announcement. We don't want everybody to copy-past this section in their reply :) Perceptions matter. A name that is repeated gets remembered. All credits go to that name while other names fade. Politicians know that perception matter. I am just educating users on how warped their perceptions could be when they thank just a single person for what is essentially the work of many hands. Users of Free Software should be appreciative of and show respect to all hands that did the grunt work. Jambunathan K.
Re: [O] Release 8.0
Jambunathan K kjambunat...@gmail.com writes: Perceptions matter. A name that is repeated gets remembered. All credits go to that name while other names fade. See this post: http://lwn.net/Articles/501751/ People still continue to thank RMS for new Emacs releases. IIRC, it is good 5-6 years since RMS retired from daily Emacs work. There is a gap between what people hold to be true and what the reality is. Some perceptions are wrong and it is important that these be corrected. Jambunathan K.
Re: [O] Release 8.0
Jambunathan K kjambunat...@gmail.com writes: Bastien b...@gnu.org writes: Jambunathan K kjambunat...@gmail.com writes: You speak as though other people don't exist or matter. IMO, you are doing a disservice to other contributors by *not* naming them. All contributors, including you, have been thanked in the release notes I attached with the original announcement. We don't want everybody to copy-past this section in their reply :) Perceptions matter. A name that is repeated gets remembered. There is very little danger that your name will not be remembered.
Re: [O] Release 8.0
Thanks to everybody who made this release possible.
Re: [O] Best practices for literate programming [was: Latex export of tables]
Aloha Rasmus, Rasmus ras...@gmx.us writes: The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. Thomas, Tom, do tell us more about what these habits are. The new exporter is really your friend. Where before I might choose to generate a LaTeX block, now I look to generate Org output and then count on the exporter to do the right thing on the way to pdf. The exporter's attribute system is very easy to use. The attributes you need to access are always right there. I've also come to rely on filters quite a bit. I use them for non-breaking spaces, the plus/minus symbol, and for the multiple citation commands used by biblatex (e.g., \parencites). There seems to be a move afoot to collect filters so they can be widely distributed. I'd like to see the filters go to the Library of Babel, but for reproducible research it is probably best to keep them with the source document so there is no doubt about the fidelity of filter code. I too rely heavily on filters and customizations. I haven't been able to fully appreciate the asynchronous exporter yet. For instance I set some defaults for tables, pictures, add lots of entities etc. in my init file, and I went as far as writing a separate init file just loading just the org stuff. Now, this is clearly /not/ a very reproducible way of doing this. I suppose this depends on what is meant by reproducible. My goal is to produce a compendium as defined by Gentleman and Lang (see Gentleman R, Lang DT (2004). Statistical Analyses and Reproducible Research. Technical report, Bioconductor Project. URL http://www.bepress.com/bioconductor/paper2). I keep the init.el file as a babel source block with the reproducible document, so it can be tangled. I also have an editing setup in a babel source block that activates many of the same features handled by the init.el file, but also configures the new exporter to look for init.el (which might have a different name). The filters are all part of the Org document, too, and get pulled into the init.el file with noweb references. A compendium with this structure gets past the problem, often aired on the ML, that there is something in my setup that causes unexpected behavior. The Org setup is completely contained in the compendium. I am able to distribute the compendium, typically as a single document (sometimes with associated data files produced by an on-line service that can't be used programmatically), which I believe is a good step toward reproducibility. Of course, it leaves open the question of changes in the underlying software. This is a real problem. Org 8.0, with its new (and sweet) exporter has broken my first two compendia. Conceivably, changes in Emacs might break a compendium, as could changes in all the other software referenced by babel code blocks. Aaron Ecay seems to be on to a possible mechanism to take care of at least some of this. AFAICT, however, his solution doesn't change the utility of the compendium, which seems to me an integral part of the reproducibility equation. What do you think? So I'm really interested in hearing or seeing implementation where the goal is reproducibility. On one hand I can appreciate keeping Org close to a vanilla state. On the other hand, I'd have to overwrite defaults every time (e.g. I /always/ want booktab tables). I guess I could keep an emacs-lisp block in the top of the file specifying stuff, but it also seems kind of tedious (copy-pasting every time). (Perhaps this could be resolved by loading external files hosted somewhere accessible). Some journals specify which LaTeX packages can or cannot be used. PLOS-One, for instance, doesn't use booktab tables, so a reproducible research document sent to them couldn't include your default setting. My sense of the publishing world is that it is sufficiently variable eventually to break almost any default you might hope to establish. Incidentally, I think this is an area ripe for growth within Org mode--additions to the Library of Babel that configure a compendium to produce LaTeX code that meets the requirements of particular publishing venues. It would be ideal to do something like init-plos-one and then, when the journal sends back your paper with a digital pink slip, change that to something like init-nature and send it off again. All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
Re: [O] New maintainer
Jambunathan K writes: Bastien b...@gnu.org writes: And it does not take too big a brain to understand why: if people were allowed to retract their assignment when they want for changes that have been published, the copyright assignment process would undermine the whole purpose of the GPL license, which is to make it possible to let *others* contribute to free code. As a maintainer of GNU project, I expect that you should have a basic understanding of the purpose of the copyright assignment and GPL license. From what I read above, I am not convinced that you have the right understanding. Your articulation is clearly confusing and falling short. As a former teacher of copyright law (University of Sydney), I think that Bastien displays a very clear understanding of the effects of copyright assignment. Your understanding is less than clear. Bastien gets a Distinction in my class. You do not. Of course, I know that you will think that I am confused. Bastien, thanks for your patience and help during your time in the hotseat. You've done a marvelous job. See http://www.gnu.org/licenses/gpl-faq.html#AssignCopyright You assign copyright to FSF so that you don't have to enforce GPL. By assigning, one outsources the legal work of actual enforcing to FSF. Single holder of rights just makes the legal procedures lot more easy. A contract that cannot be enforced is worthless. A license that you cannot enforce is equally so. FSF says, assign me the rights, I will go after all the violators and force them to comply with GPL. Jambunathan K. -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] New maintainer
Bastien writes: Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. Thumbs up! And thank you so much for what you did. Alan
Re: [O] New maintainer
Aloha Bastien, Bastien b...@gnu.org writes: Dear all, I'm stepping down as the Org maintainer. Thank you for your excellent work as maintainer. I'm pleased to have had the opportunity to work with you. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. Yes, thumbs up. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! You should be proud that you're giving back a much improved piece of software. From my point of view, the new exporter framework is a huge step forward. Congratulations! All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] New maintainer
Hi Thomas, t...@tsdye.com (Thomas S. Dye) writes: Thank you for your excellent work as maintainer. I'm pleased to have had the opportunity to work with you. Having you improve the documentation while Nicolas and I were hard working on it was a great relief, thanks again for that. You should be proud that you're giving back a much improved piece of software. From my point of view, the new exporter framework is a huge step forward. Congratulations! Yes -- I second Carsten's surprise that someone was crazy enough to undertake this enormous work. And its potential still waits to be completely unfold! -- Bastien
Re: [O] Release 8.0
Jambunathan K kjambunat...@gmail.com writes: Can you name the person who funds http://orgmode.org website? Indeed, I forget to add Jason Dunsmore in the list of people to thank. Sorry for that. Jason is still helping with anything regarding the server, we are lucky to have him! -- Bastien
Re: [O] New maintainer
Jambunathan K writes: Alan L Tyree alanty...@gmail.com writes: Of course, I know that you will think that I am confused. You are not only confused. You are in hurry and in grave error. I thought so. Thanks so much for clearing this up for me. I am quoting an extract of Bastien's words, the copyright assignment process would undermine the whole purpose of the GPL license It is wrong to say copyright assigment will undermine the purpose of GPL license. Copyright assignment is there to bolster the enforcement of GPL. I provided a reference. My claim is that there is no assignment. Because out of my own initiative I informed FSF that this work is not covered by contract and also cancelled the assignment. How do you interpret the following block extracted from my assignment , | 2. Developer will report occasionally, on Developer’s initiative | and whenever requested by FSF, the changes and/ or enhancements | which are covered by this contract, and (to the extent known to | Developer) any outstanding rights, or claims of rights, of any | person, that might be adverse to the rights of Developer or FSF | or to the purpose of this contract. ` FSF clearly side-steps the important question - when is a work actually assigned. Assignment is not a process but an event tied to specific time and date. Will you disagree if I claim - The intent to act is not the act itself. Replacement act with whatever. Jambunathan K. -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] New maintainer
Hello Bastien, On 18 April 2013 12:53, Bastien b...@gnu.org wrote: Dear all, I'm stepping down as the Org maintainer. Thank you for all the work you've done. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. Thumbs up from me as well. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) -- Bastien -- Jon
Re: [O] Release 8.0
Jambunathan K kjambunat...@gmail.com writes: There is very little danger that your name will not be remembered. Let me be clear, it's not about me. I am a nobody who likes to troll. Confession noted. In which case it IS all about you. It is about others (as well) who deserve a explicit word of thanks. So far you have totally failed to offer any word of thanks - either to Bastien or to any one else. [1] Why cannot people thank Nicolas Goaziou for the parser and exporter framework and also for most of the exporters. Why can't you? People are under the mistaken notion that it is the maintainer who does the most or important work. It is this mistake I am endeavouring to correct. Obviously I am failing. You are failing because the 'mistaken notion' you are trying to correct does not exist. Glyn Footnotes: [1] Anyone else? Lots of attributions here - http://orgmode.org/Changes.html - you are all wonderful and I love you!
Re: [O] Fixing footnote HTML
Hi Bastien, On 3/24/13, Bastien b...@altern.org wrote: So in Firefox for me at least, there is no blank line between Footnotes: and 1. Footnotes: is inserted as a h2 header in the HTML file. So there should be a visual space after it. I don't know why there isn't. I guess it means CSS is required? I have the 1 of the first footnote appearing on the next line without a blank line. In any case sounds like a non-Org bug, but wanted. Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] Enriched/Org is a colorful Org
I want to add to the thanks to everybody for making speed improvements. -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is NO hope without action. This means YOU.
Re: [O] [babel] Specified colnames
Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Extra question: tested with a sh block, both of the above do work, that is with strings or symbols. Which one is supposed to be better (that is, will be more portable with time), if there is one? Both will be maintained. The contribution of a test exercising both options could provide an extra guarantee of perseverance. This is also a good first step towards editing the code. :) Here's my trial to do so [...]. Does this correspond to what you're asking for? Close, could you prepare this as a patch against the current code base? That way I can simply apply it locally and more easily test it. I've fixed the abortion problem I had with the test... Updated version: --8---cut here---start-8--- (ert-deftest test-ob/specific-colnames () Test passing specific column names. (should (equal #+name: input-table | id | var1 | |+--| | 1 | bar | | 2 | baz | #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) echo \$data\ #+end_src #+results: | Rev | Author | |-+| | 1 | bar| | 2 | baz| (org-test-with-temp-text #+name: input-table | id | var1 | |+--| | 1 | bar | | 2 | baz | #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) echo \$data\ #+end_src (org-babel-execute-src-block) (buffer-string) --8---cut here---end---8--- Though, it generates an incomprehensible error (for me): --8---cut here---start-8--- Debugger entered--Lisp error: (wrong-type-argument consp nil) apply(debug (error (wrong-type-argument consp nil))) ert--run-test-debugger([cl-struct-ert--test-execution-info [cl-struct-ert-test test-ob/specific-colnames Test passing specific column names. (lambda nil (let ((fn-802 (function equal)) (args-803 (list #+name: input-table\n| id | var1 |\n|+--|\n| 1 | bar |\n| 2 | baz |\n\n#+begin_src sh :var data=input-table :exports results :colnames '(Rev Author)\necho \$data\\n#+end_src\n\n#+results:\n| Rev | Author |\n|-+|\n| 1 | bar|\n| 2 | baz|\n\n (let ... ... (let ((value-804 (quote ert-form-evaluation-aborted-805))) (let (form-description-806) (if (unwind-protect ... ... ...) nil (ert-fail form-description-806))) value-804))) nil :passed nil] [cl-struct-ert-test-failed nil nil (wrong-type-argument consp nil) ((t setcar nil ((:comments . ) (:shebang . ) (:cache . ) (:padline . ) (:noweb . ) (:tangle . ) (:exports . ) (:results . ))) (nil let* ((c (nthcdr 2 i))) (setcar c merged-params)) (nil let ((i info)) (let* ((c (nthcdr 2 i))) (setcar c merged-params)) i) (nil org-babel-check-evaluate (let ((i info)) (let* ((c ...)) (setcar c merged-params)) i)) (nil if (org-babel-check-evaluate (let ((i info)) (let* (...) (setcar c merged-params)) i)) (progn (let* ((params ...) (cachep ...) (new-hash ...) (old-hash ...) (cache-current-p ...)) (cond (cache-current-p ...) (... ...) (nil let* ((info (if info (copy-tree info) (org-babel-get-src-block-info))) (merged-params (org-babel-merge-params (nth 2 info) params))) (if (org-babel-check-evaluate (let (...) (let* ... ...) i)) (progn (let* (... ... ... ... ...) (cond ... ...) (t org-babel-execute-src-block) (nil progn (org-mode) (progn (insert #+name: input-table\n| id | var1 |\n|+--|\n| 1 | bar |\n| 2 | baz |\n\n#+begin_src sh :var data=input-table :exports results :colnames '(Rev Author)\necho \$data\\n#+end_src\n) (goto-char (point-min))) (org-babel-execute-src-block) (buffer-string)) (nil unwind-protect (progn (org-mode) (progn (insert #+name: input-table\n| id | var1 |\n|+--|\n| 1 | bar |\n| 2 | baz |\n\n#+begin_src sh :var data=input-table :exports results :colnames '(Rev Author)\necho \$data\\n#+end_src\n) (goto-char (point-min))) (org-babel-execute-src-block) (buffer-string)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer))) (nil save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (org-mode) (progn (insert #+name: input-table\n| id | var1 |\n|+--|\n| 1 | bar |\n| 2 | baz |\n\n#+begin_src sh :var data=input-table :exports results :colnames '(Rev Author)\necho \$data\\n#+end_src\n) (goto-char ...)) (org-babel-execute-src-block) (buffer-string)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer (nil let ((temp-buffer (generate-new-buffer *temp*))) (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (org-mode) (progn ... ...) (org-babel-execute-src-block) (buffer-string)) (and (buffer-name temp-buffer) (kill-buffer temp-buffer) (nil list #+name: input-table\n| id | var1 |\n|+--|\n| 1 | bar |\n| 2 | baz |\n\n#+begin_src sh :var data=input-table :exports results :colnames
Re: [O] New maintainer
Hi everybody, I'm just an Org user, one of the many anonymous persons who have benefited from this fantastic piece of software. Over the past two years I have come to use Org every day, all day long, more than any other application with the possible exception of a Web browser. It's hard to overestimate the value I receive from Org, the sheer personal effectiveness I've gained. Bastien, a thousand thanks for your work as maintainer. Thanks as well to all the other skillful and creative programmers on this list who make org continually more powerful and astonishing. Especial thanks to Carsten, both for the past and now in advance as the new maintainer. With grateful regards to all, Tom Davey -- Tom Davey t...@tomdavey.com New York NY USA
Re: [O] Release 8.0
On 18.4.2013, at 18:41, Bastien b...@gnu.org wrote: Dear all, I'm releasing Org 8.0. See the release notes below or at http://orgmode.org/Changes.html This is a beautiful release. Just reading the list of changes wets my appetite to try it all out. A looong list con contributors. Thanks to you all for your contributions! - Carsten
[O] Changing the maintainer
Hello everyone, as Bastien has written in a related thread, the current idea is that I will take over the maintainership of Org-mode once more. I have seen no objections so far, so I am assuming that we should go ahead with this plan. Let me start by extending my (and I am sure, everyones) gratitude to Bastien. I think he has done an incredible job over the last two years, keeping Org-mode on course and also supporting significant changes that we have seen with the release of version 8.0. Bastien's activity has been unmatched. He has answered a huge amount of questions in the mailing list, fixed an uncounted number of bugs and he has been designing and applying changes over the entire breadth of the Org code base. This is no easy feat and I really admire his work. Besides this, he has done amazing work keeping the community together and making sure that the mailing list remains IMO one of the prime places on the internet. THANK YOU, Bastien. I will leave the donations button on his name until the end of April, so if you want to express your thanks to him in this way, you have that possibility. If not, writing to him and expressing your amazement with his achievements in the last two years will probably make him as happy. One of the main things Bastien has done is to make space for other developers, while making sure that the development maintains a maximum of compatibility, usability and hackability. It has taken a long time to get the new exporter into the main stream, and I clearly think it was worth the wait. We now have a complete set of exporters, immediately in the first release that is based on the new parser and exporter framework. What Nicolas has achieved I still cannot fully comprehend. The exporter side of Org-mode was very usable, but it was an unmaintainable mess, without clarity. Now, writing a new exporter has become extremely simple, everyone can do it. Due to the ingenious filter and inheritance system, new exporters can be written with very little code. Maintenance will be simple, since this is ONE parser, one framework. When I handed over the maintainership to Bastien two years ago, I was worn down. In the mean time, my life has not become less full, and so this time around, I will make sure that the project does not swallow me. I hope very much that we as a community can continue on the path Bastien has set, with a growing number of people taking responsibility for specific parts of Org. I need to re-familiarize myself with many things, I am not up to speed with some of the new developments, so I need to study. But when this is done, I will approach some of you and ask for help, it would be great if some of you can say yes and work with me. I will see my own task mainly in removing obstacles for everyone, and in coordinating releases. I also have coding ideas and plans, but those will have second priority. I am really glad that Bastien has promised to stick around, and he will still lead the round of fixes that usually follow after a major release. I am looking forward to again interact more with you all. Cheers - Carsten
Re: [O] Release 8.0
Bastien b...@gnu.org writes: I'm releasing Org 8.0. Great work! Wow what a huge list of new things to try :) I'm looking forward to experimenting with it. Thanks!! Bernt
Re: [O] New maintainer
Bastien bzg at gnu.org writes: Dear all, I'm stepping down as the Org maintainer. You have done an awesome job. This is still the friendliest little town on the internet thanks to your patience and good judgment in no small part. And 8.0 is a fine product. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. +2 thumbs Gmane requires me to type the capcha 'uplift' to send this message. How appropriate! All the Best,
Re: [O] New maintainer
Bastien b...@gnu.org writes: Dear all, I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) Dear Bastien and Carsten, Thanks, Bastien, for doing an awesome job as the org-mode maintainer these past few years. You had a huge job filling Carsten's shoes and you did an excellent job. I really appreciate all of the work you have done as our org-mode maintainer and hope you will continue to contribute in the future. Welcome back Carsten! Please let us know how we can help make your job easier. None of us have infinite time to devote to this excellent project but I'm sure we can help lessen the burden that maintaining this beast must be. I use this awesome tool everyday and really appreciate the thought and effort put into making org-mode the fabulous tool that it is. /me can't draw two thumbs up in Ascii without making it look obscene ;) Warmest regards, Bernt
Re: [O] New maintainer
Hello Bastien, Thanks a lot for the great work so far. You are the best. On Apr 19 2013, Bastien b...@gnu.org wrote: Dear all, I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) Thanks., -- ఎందరో మహానుభావులు అందరికి వందనములు. YYR
Re: [O] Changing the maintainer
On Apr 18, 2013, at 6:07 PM, Carsten Dominik carsten.domi...@gmail.com wrote: I will leave the donations button on his name until the end of April, so if you want to express your thanks to him in this way, you have that possibility. If not, writing to him and expressing your amazement with his achievements in the last two years will probably make him as happy. Bastien - I have not contributed any where near as much as I would have liked to over the past few year (especially given what I “get out” of Org mode and the exporters). I hope my small donation in some way makes up for it. I do know that every time I found something “odd” it was always difficult and took me a bunch of time to even get a reasonable ECM and despite that you seemed to always get to the heart of the problem and quickly push a fix. Thank YOU!
[O] org-macro need to provide org-macs
Just add (require 'org-macs) in org-macro.el. -- Elle n'était vêtue que de bonnes fortunes du jeu ou de la sottise de ses amants. -- Antoine Furetière
Re: [O] New maintainer
Bastien, I use org-mode every day and it is really great to see that this project is always growing. You did an excellent job taking this to 8.0. Carsten, Welcome back and looking forward to 8.x Thanks and Regards Noorul On Thu, Apr 18, 2013 at 10:23 PM, Bastien b...@gnu.org wrote: Dear all, I'm stepping down as the Org maintainer. Carsten accepted to step up, if the community agrees. Please raise your thumbs up or your concerns, if any. I'm glad I had this opportunity to work as Robin and I'm even more glad Batman may strike back! :) -- Bastien
Re: [O] Changing the maintainer
Carsten Dominik carsten.domi...@gmail.com writes: Bastien's activity has been unmatched. He has answered a huge amount of questions in the mailing list, fixed an uncounted number of bugs and he has been designing and applying changes over the entire breadth of the Org code base. This is no easy feat and I really admire his work. Besides this, he has done amazing work keeping the community together and making sure that the mailing list remains IMO one of the prime places on the internet. Couldn't agree more. Thank you so much, Bastien! And to everyone who has helped to keep Org-mode one of Emacs' killer apps for several years running. John
Re: [O] Release 8.0
On 18 Apr 2013 18:05, Carsten Dominik carsten.domi...@gmail.com wrote: On 18.4.2013, at 18:41, Bastien b...@gnu.org wrote: Dear all, I'm releasing Org 8.0. This is a beautiful release. Just reading the list of changes wets my appetite to try it all out. A looong list con contributors. Thanks to you all for your contributions! An intimidatingly long list of changes, actually. :-) For what it is worth, I think if Bastien erred in the list of contributors he thanked, it was on the side of over-inclusion, rather than under. In the last year or so, I think I've contributed a tiny change doc patch, a bug report or two, and a few Please, could someone magically make it work like this? messages, yet I find myself included. Congrats and thanks to all who helped in whatever way. The efforts from the heroic and steady to minor and irregular have all helped to make my life better. Best, Brian vdB
