Re: [O] Prepare release 8.2.6
Just checked it with Org-mode version 8.2.6 (release_8.2.6-936-gd9e6bd @ /Users/rainerkrug/.emacs.d/org-mode/lisp/) and it works there. Cheers, Rainer Bastien writes: > Hi Rainer, > > Rainer M Krug writes: > >> This has been introduced within the previous week, if I am not >> mistaken. > > Can you try to bisect a bit more? Maybe look for a commit that > changed property inheritance, as it looks like it's related. > > Thanks, -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgp4Hz2V7Gpq8.pgp Description: PGP signature
Re: [O] Prepare release 8.2.6
Hi Rainer, Rainer M Krug writes: > This has been introduced within the previous week, if I am not > mistaken. Can you try to bisect a bit more? Maybe look for a commit that changed property inheritance, as it looks like it's related. Thanks, -- Bastien
Re: [O] Prepare release 8.2.6
Hi Michael and Nicolas, Nicolas Goaziou writes: > It needs to be discussed, but I tend to think that it would be better to > allow newlines characters in macros and inline babel calls, even if it > means replacing them with a space when needed. I've given this another thought and I agree here. Prevent line breaks here would look weird, and adding the space when needed looks easy enough (at least, it's easy enough to suppose it is easy... not sure about the details.) -- Bastien
Re: [O] Prepare release 8.2.6
Hi Michael, "R. Michael Weylandt" writes: > The attached should apply cleanly against master. Applied, thanks, -- Bastien
Re: [O] Prepare release 8.2.6
On Thu, Apr 10, 2014 at 10:43 PM, Eric Schulte wrote: > > I just tried to apply the second patch, but it no longer applies (with > "git am") to the Org-mode repo. Would you mind sending along an updated > version? > Hi Eric, The attached should apply cleanly against master. Michael 0001-Keybinding-to-remove-result-blocks.patch Description: Binary data
Re: [O] Prepare release 8.2.6
"R. Michael Weylandt" writes: > On Sat, Apr 5, 2014 at 3:27 PM, Nicolas Goaziou wrote: >> Hello, >> >> Would you mind adding a commit message, TINYCHANGE at its end, and send >> it again with "git format-patch"? > > Hi Nicolas, > > Thanks for taking the time to review my patches (2 attached): > hopefully these are formatted to org standards. > I just tried to apply the second patch, but it no longer applies (with "git am") to the Org-mode repo. Would you mind sending along an updated version? Thanks, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] Prepare release 8.2.6
Hello,
"R. Michael Weylandt" writes:
> I'm not as familiar with org-element-context, but I think the attached
> is what you had in mind.
Thanks. Comments follow.
>> Another option for the problem at hand is to simply remove newline
>> characters in inline source blocks before executing them.
>
> That might be better but would require a bit more work:
It would require more work, but adding functions to
`fill-nobreak-predicate' has a cost, too.
It needs to be discussed, but I tend to think that it would be better to
allow newlines characters in macros and inline babel calls, even if it
means replacing them with a space when needed.
> at present,
> inline source blocks can't extend over multiple lines so org wouldn't
> recognize a construct like
>
> src_python[:exports results]{1 + 2 +
> 3 + 4}
>
> as an inline source block in the first place. Looking at
> org-inline-src-block-regexp I'm not sure why though.
Because there is everywhere [^...\n...], which means "no newline
characters, please". The same goes for ".*?", as "." cannot match
a newline character.
> +(defun org-fill-element-nobreak-p ()
Technically, it is about "objects", not elements. So the function could
be named `org-fill-objects-nobreak-p'.
> + "Non-nil when a new line at point would break an element which
> + cannot be split over multiple lines."
Ditto. Also the first sentence in the docstring cannot be split into two
lines.
> + (member (car (org-element-context))
> + '(inline-src-block macro)))
(memq (org-element-type (org-element-context))
...)
Regards,
--
Nicolas Goaziou
Re: [O] Prepare release 8.2.6
Bastien writes: > Hi all, > > I'll spend a few hours this afternoon chasing the last > bugs in maint for Org 8.2.6. This release will then be > merged into the emacs-24 branch, which first pretest is > to be released very soon now. > > If you have outstanding bugs, please point at them. > > As usual, thanks in advance for your help, > > PS: gmane.org seems to be down since April, 1st, so I > could not follow the discussions since that time. Sorry if this has ben already received the list, but I must have missed it. I don't know if this effects the release of 8.2.6, but I have a bug which I would consider as serious. Using the following as the org file, results in the error in R during export to latex / pdf: --8<---cut here---start->8--- #+TITLE: single_to_multi #+DATE: <2013-10-15 Tue> #+AUTHOR: Rainer M. Krug #+EMAIL: rai...@krugs.de #+PROPERTY: session *R_MOBILIS* * R functions :PROPERTIES: :eval: never :END: Some function definitions and setting up of the compouting environment. The functions are in the ~./R/~ folder, while the data has been stored in the ~./data/~ folder as an ~.rda~ file. These can be put into a package later. ** Data IO Functions Some functions to for interaction with SQLite database. *** IFN data Load spatial forest inventory data * Data Assessment Results ** IFN *** Load spatial forest inventory data #+begin_src R :results output IFN.raw <- "Here it is" #+end_src *** Maps Raw point data The data from the raw points is plotted as maps. #+begin_src R :results output cat(IFN.raw) #+end_src * Versions: - org :: Org-mode version 8.2.5h (release_8.2.5h-879-g23e62f @ /Users/rainerkrug/.emacs.d/org-mode/lisp/) - emacs :: GNU Emacs 24.3.1 (x86_64-apple-darwin13.0.0, Carbon Version 1.6.0 AppKit 1265) of 2014-02-13 on Rainers-MacBook-Pro-2.local --8<---cut here---end--->8--- The error is: , | > cat(IFN.raw) | 'org_babel_R_eoe' | Error in cat(IFN.raw) : object 'IFN.raw' not found | > [1] "org_babel_R_eoe" | > ` In other words, the second code block is evaluated, but the second one not. If I remove the :evel: property *in the previous* tree, it works as expected. But in the main document, I have code in there which I do not want to have evaluated. This has been introduced within the previous week, if I am not mistaken. Cheers, Rainer -- Rainer M. Krug PGP: 0x0F52F982 smime.p7s Description: S/MIME cryptographic signature smime.p7s Description: S/MIME cryptographic signature
Re: [O] Prepare release 8.2.6
On Sat, Apr 5, 2014 at 3:18 PM, Nicolas Goaziou wrote:
> Hello,
>
> "R. Michael Weylandt" writes:
>
>>> 1) Tell Emacs not to break inline source blocks when filling paragraphs:
>
> I suggest not to use `org-in-regexp' here but `org-element-context'.
I'm not as familiar with org-element-context, but I think the attached
is what you had in mind.
> Besides inline source blocks, ISTR there was other places where filling
> was inappropriate (verbatim, code, export snippet, macro...). A single
> `org-element-context' will find them all.
Verbatim seems to work over multiple lines so I've left them out.
Macros and inline source blocks don't so I've included them. Not sure
what other elements to look at:
>
> Another option for the problem at hand is to simply remove newline
> characters in inline source blocks before executing them.
>
That might be better but would require a bit more work: at present,
inline source blocks can't extend over multiple lines so org wouldn't
recognize a construct like
src_python[:exports results]{1 + 2 +
3 + 4}
as an inline source block in the first place. Looking at
org-inline-src-block-regexp I'm not sure why though.
Patch also attached to improve link handling
Michael
0001-org.el-Don-t-fill-on-inline-source-blocks-or-macros.patch
Description: Binary data
0002-org.el-Remove-and-from-org-link-escape-chars.patch
Description: Binary data
Re: [O] Prepare release 8.2.6
"R. Michael Weylandt" writes: > Thanks for taking the time to review my patches (2 attached): > hopefully these are formatted to org standards. Thank you. They look good. I applied the first one. I'll let Eric, or Bastien, decide about it. > * ob-core.el: Add a function `org-babel-remove-result-one-or-many' > which wraps `org-babel-remove-result' to map unto all src blocks when > called with a prefix arg Small note: this should simply be: * ob-core.el (org-babel-remove-result-one-or-many): New function. Regards, -- Nicolas Goaziou
Re: [O] Prepare release 8.2.6
On Sat, Apr 5, 2014 at 3:27 PM, Nicolas Goaziou wrote: > Hello, > > Would you mind adding a commit message, TINYCHANGE at its end, and send > it again with "git format-patch"? Hi Nicolas, Thanks for taking the time to review my patches (2 attached): hopefully these are formatted to org standards. > >>> 2) Add a key binding C-c C-v k for org-babel-remove result in ob-keys.el. >>> (Discussed on list but I can't find the reference) > > [...] > > > Regards, > > -- > Nicolas Goaziou 0001-ox-latex.el-downcase-language-name-in-minted-blocks.patch Description: Binary data 0002-ob-core.el-ob-keys.el-Add-a-keybinding-to-remove-res.patch Description: Binary data
Re: [O] Prepare release 8.2.6
Hi there, I reported a regression a few days ago, and I just knew that you are busy preparing a new release. Since the bug I reported is a regression, I think you may want to consider fix it before releasing the new version. Here's the bug report I copied from the other email I had sent to this list: (org-insert-headline '(4)) used to insert new heading before point. But this had broken recently. According to the docstring, this command inserts new heading at the end of the parent subtree ONLY if two universal prefix arguments is given, not one. Here's the reproducer: --8<---cut here---start->8--- emacs -Q -L path/to/org-mode/lisp/ --eval \ "(let ((buf (get-buffer-create \"test-org\"))) \ (with-current-buffer buf \ (org-mode) \ (insert \"* headline 1\") \ (goto-char (line-beginning-position)) \ (org-insert-heading '(4))) \ (switch-to-buffer buf))" --8<---cut here---end--->8--- Thanks, York On Sat, Apr 5, 2014 at 3:27 PM, Nicolas Goaziou wrote: > Hello, > > "R. Michael Weylandt" writes: > >>> A few more minor things from my .emacs: >>> >>> 1) In ox-latex.el, add a `downcase` around the definition of >>> mint-lang in org-latex-inline-src-block and the sexp `(or (cadr >>> (assq (intern lang) org-latex-minted-langs)) lang)` in >>> org-latex-src-block to respect minted's convention of putting all >>> language names in lowercase. > > Thank you. > > Would you mind adding a commit message, TINYCHANGE at its end, and send > it again with "git format-patch"? See > > http://orgmode.org/worg/org-contribute.html > > for more information. > >>> 2) Add a key binding C-c C-v k for org-babel-remove result in ob-keys.el. >>> (Discussed on list but I can't find the reference) > > [...] > > > Regards, > > -- > Nicolas Goaziou >
Re: [O] Prepare release 8.2.6
Hello, "R. Michael Weylandt" writes: >> A few more minor things from my .emacs: >> >> 1) In ox-latex.el, add a `downcase` around the definition of >> mint-lang in org-latex-inline-src-block and the sexp `(or (cadr >> (assq (intern lang) org-latex-minted-langs)) lang)` in >> org-latex-src-block to respect minted's convention of putting all >> language names in lowercase. Thank you. Would you mind adding a commit message, TINYCHANGE at its end, and send it again with "git format-patch"? See http://orgmode.org/worg/org-contribute.html for more information. >> 2) Add a key binding C-c C-v k for org-babel-remove result in ob-keys.el. >> (Discussed on list but I can't find the reference) [...] Regards, -- Nicolas Goaziou
Re: [O] Prepare release 8.2.6
Hello, "R. Michael Weylandt" writes: >> 1) Tell Emacs not to break inline source blocks when filling paragraphs: >> >> http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01310.html > > Small patch in support: Thank you. > +(defun org-in-inline-src-block-p () > + "Test if within an inline src block." > + (org-in-regexp org-babel-inline-src-block-regexp)) I suggest not to use `org-in-regexp' here but `org-element-context'. > - org-fill-paragraph-with-timestamp-nobreak-p) > + org-fill-paragraph-with-timestamp-nobreak-p > + org-in-inline-src-block-p) Besides inline source blocks, ISTR there was other places where filling was inappropriate (verbatim, code, export snippet, macro...). A single `org-element-context' will find them all. Another option for the problem at hand is to simply remove newline characters in inline source blocks before executing them. Regards, -- Nicolas Goaziou
Re: [O] Prepare release 8.2.6
On Fri, Apr 4, 2014 at 10:32 AM, Michael Weylandt
wrote:
>
>
> On Apr 3, 2014, at 2:37, Bastien wrote:
>
>> Hi all,
>>
>> I'll try to fix a few remaining bugs in maint this afternoon
>> then release 8.2.6 so that we can merge it into Emacs emacs-24
>> branch, the pretest is scheduled to happen as soon as possible.
>>
>> If you have important bugs you want us to look at, now is the
>> time to point at them.
>
> A few more minor things from my .emacs:
>
> 1) In ox-latex.el, add a `downcase` around the definition of mint-lang in
> org-latex-inline-src-block and the sexp `(or (cadr (assq (intern lang)
> org-latex-minted-langs)) lang)` in org-latex-src-block to respect minted's
> convention of putting all language names in lowercase.
>
Patches:
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 59e6e83..013c731 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1474,9 +1474,9 @@ contextual information."
;; Use minted package.
((eq org-latex-listings 'minted)
(let* ((org-lang (org-element-property :language inline-src-block))
-(mint-lang (or (cadr (assq (intern org-lang)
+(mint-lang (downcase (or (cadr (assq (intern org-lang)
org-latex-minted-langs))
- org-lang))
+ org-lang)))
(options (org-latex--make-option-string
org-latex-minted-options)))
(concat (format "\\mint%s{%s}"
@@ -2116,7 +2116,7 @@ contextual information."
("firstnumber" ,(number-to-string (1+ num-start
org-latex-minted-options)))
;; Language.
-(or (cadr (assq (intern lang) org-latex-minted-langs)) lang)
+(downcase (or (cadr (assq (intern lang)
org-latex-minted-langs)) lang))
;; Source code.
(let* ((code-info (org-export-unravel-code src-block))
(max-width
> 2) Add a key binding C-c C-v k for org-babel-remove result in ob-keys.el.
> (Discussed on list but I can't find the reference)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index e8943c6..c73c42b 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2166,6 +2166,15 @@ code the results are extracted in the
syntax of the source
(goto-char location) (forward-line 1)
(delete-region start (org-babel-result-end))
+(defun org-babel-remove-result-one-or-many (x)
+ "Remove the result of the current source block.
+If called with a prefix argument, remove all result blocks
+in the buffer."
+ (interactive "P")
+ (if x
+ (org-babel-map-src-blocks nil (org-babel-remove-result))
+(org-babel-remove-result)))
+
(defun org-babel-result-end ()
"Return the point at the end of the current set of results."
(save-excursion
diff --git a/lisp/ob-keys.el b/lisp/ob-keys.el
index 90b5196..dc1f437 100644
--- a/lisp/ob-keys.el
+++ b/lisp/ob-keys.el
@@ -89,6 +89,7 @@ functions which are assigned key bindings, and see
("h" . org-babel-describe-bindings)
("\C-x" . org-babel-do-key-sequence-in-edit-buffer)
("x" . org-babel-do-key-sequence-in-edit-buffer)
+("k" . org-babel-remove-result-one-or-many)
("\C-\M-h" . org-babel-mark-block))
"Alist of key bindings and interactive Babel functions.
This list associates interactive Babel functions
>
> I actually wrap it so C-u C-c C-v k calls
>
> (org-babel-map-src-blocks nil (org-babel-remove-result))
>
>>
>> Thanks,
>>
>> --
>> Bastien
>>
>>
Re: [O] Prepare release 8.2.6
On Fri, Apr 4, 2014 at 7:51 AM, Michael Weylandt wrote: > > > On Apr 3, 2014, at 2:37, Bastien wrote: > > Hi all, > > I'll try to fix a few remaining bugs in maint this afternoon > then release 8.2.6 so that we can merge it into Emacs emacs-24 > branch, the pretest is scheduled to happen as soon as possible. > > If you have important bugs you want us to look at, now is the > time to point at them. > > > Hi Bastien, > > Two small usability issues you may want to take a look at: > > 1) Tell Emacs not to break inline source blocks when filling paragraphs: > > http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01310.html Small patch in support: diff --git a/lisp/org-src.el b/lisp/org-src.el index f870b2c..32de2a1 100644 --- a/lisp/org-src.el +++ b/lisp/org-src.el @@ -40,6 +40,7 @@ (declare-function org-do-remove-indentation "org" (&optional n)) (declare-function org-at-table.el-p "org" ()) (declare-function org-in-src-block-p "org" (&optional inside)) +(declare-function org-in-inline-src-block-p "org" ()) (declare-function org-in-block-p "org" (names)) (declare-function org-get-indentation "org" (&optional line)) (declare-function org-switch-to-buffer-other-window "org" (&rest args)) diff --git a/lisp/org.el b/lisp/org.el index 318d95a..2778160 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -21536,6 +21536,9 @@ when point is at #+BEGIN_SRC or #+END_SRC." (beginning-of-line) (looking-at ".*#\\+\\(begin\\|end\\)_src"))) +(defun org-in-inline-src-block-p () + "Test if within an inline src block." + (org-in-regexp org-babel-inline-src-block-regexp)) (defun org-context () "Return a list of contexts of the current cursor position. If several contexts apply, all are returned. @@ -22246,7 +22249,8 @@ hierarchy of headlines by UP levels before marking the subtree." (org-uniquify (append fill-nobreak-predicate '(org-fill-line-break-nobreak-p - org-fill-paragraph-with-timestamp-nobreak-p) + org-fill-paragraph-with-timestamp-nobreak-p + org-in-inline-src-block-p) (let ((paragraph-ending (substring org-element-paragraph-separate 1))) (org-set-local 'paragraph-start paragraph-ending) (org-set-local 'paragraph-separate paragraph-ending)) > > 2) Allow =, +, and ; to be entered into org-insert-link. The list of > character is org-link-escape-chars seems to be unnecessarily defensive and > results in bad links being entered into documents (and then exported). > > http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg00990.html > > Michael > > > Thanks, > > -- > Bastien > >
Re: [O] Prepare release 8.2.6
On Apr 3, 2014, at 2:37, Bastien wrote: > Hi all, > > I'll try to fix a few remaining bugs in maint this afternoon > then release 8.2.6 so that we can merge it into Emacs emacs-24 > branch, the pretest is scheduled to happen as soon as possible. > > If you have important bugs you want us to look at, now is the > time to point at them. A few more minor things from my .emacs: 1) In ox-latex.el, add a `downcase` around the definition of mint-lang in org-latex-inline-src-block and the sexp `(or (cadr (assq (intern lang) org-latex-minted-langs)) lang)` in org-latex-src-block to respect minted's convention of putting all language names in lowercase. 2) Add a key binding C-c C-v k for org-babel-remove result in ob-keys.el. (Discussed on list but I can't find the reference) I actually wrap it so C-u C-c C-v k calls (org-babel-map-src-blocks nil (org-babel-remove-result)) > > Thanks, > > -- > Bastien > >
Re: [O] Prepare release 8.2.6
On Apr 3, 2014, at 2:37, Bastien wrote: > Hi all, > > I'll try to fix a few remaining bugs in maint this afternoon > then release 8.2.6 so that we can merge it into Emacs emacs-24 > branch, the pretest is scheduled to happen as soon as possible. > > If you have important bugs you want us to look at, now is the > time to point at them. Hi Bastien, Two small usability issues you may want to take a look at: 1) Tell Emacs not to break inline source blocks when filling paragraphs: http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01310.html 2) Allow =, +, and ; to be entered into org-insert-link. The list of character is org-link-escape-chars seems to be unnecessarily defensive and results in bad links being entered into documents (and then exported). http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg00990.html Michael > > Thanks, > > -- > Bastien > >
Re: [O] Prepare release 8.2.6
Hi Bastien, Bastien wrote: > I'll try to fix a few remaining bugs in maint this afternoon then > release 8.2.6 so that we can merge it into Emacs emacs-24 branch, the > pretest is scheduled to happen as soon as possible. > > If you have important bugs you want us to look at, now is the time to > point at them. As already mentioned before, I'd advocate trying to solve the following 2 bugs before merging back into Emacs: - #16440: Some colors of the theme aren't respected in latest Emacs - #15298: Background color lost when highlighting a string As well, I don't know whether this is an Org or an Emacs problem, but I can crash Emacs 24.3.50.1 (r114715, for the sake of completeness) quite easily when capturing an Org item. Reported to Emacs as bug #16780. I retested it this morning with an up-to-date Org. Note that the same capture process does not crash on the current Emacs I do use (Emacs 24.4.50.1, r116906 of 2014-03-30)... But would it crash for Org users in the wild (using different Emacs versions)? Thanks, Seb -- Sebastien Vauban
[O] Prepare release 8.2.6
Hi all, I'll try to fix a few remaining bugs in maint this afternoon then release 8.2.6 so that we can merge it into Emacs emacs-24 branch, the pretest is scheduled to happen as soon as possible. If you have important bugs you want us to look at, now is the time to point at them. Thanks, -- Bastien
Re: [O] Prepare release 8.2.6
Bastien writes: > Hi all, > > I'll spend a few hours this afternoon chasing the last > bugs in maint for Org 8.2.6. This release will then be > merged into the emacs-24 branch, which first pretest is > to be released very soon now. > > If you have outstanding bugs, please point at them. > > As usual, thanks in advance for your help, > > PS: gmane.org seems to be down since April, 1st, so I > could not follow the discussions since that time. I don't know if this effects the release of 8.2.6, but I have a bug which I would consider as serious. Using the following as the org file, results in the error in R during export to latex / pdf: --8<---cut here---start->8--- #+TITLE: single_to_multi #+DATE: <2013-10-15 Tue> #+AUTHOR: Rainer M. Krug #+EMAIL: rai...@krugs.de #+PROPERTY: session *R_MOBILIS* * R functions :PROPERTIES: :eval: never :END: Some function definitions and setting up of the compouting environment. The functions are in the ~./R/~ folder, while the data has been stored in the ~./data/~ folder as an ~.rda~ file. These can be put into a package later. ** Data IO Functions Some functions to for interaction with SQLite database. *** IFN data Load spatial forest inventory data * Data Assessment Results ** IFN *** Load spatial forest inventory data #+begin_src R :results output IFN.raw <- "Here it is" #+end_src *** Maps Raw point data The data from the raw points is plotted as maps. #+begin_src R :results output cat(IFN.raw) #+end_src * Versions: - org :: Org-mode version 8.2.5h (release_8.2.5h-879-g23e62f @ /Users/rainerkrug/.emacs.d/org-mode/lisp/) - emacs :: GNU Emacs 24.3.1 (x86_64-apple-darwin13.0.0, Carbon Version 1.6.0 AppKit 1265) of 2014-02-13 on Rainers-MacBook-Pro-2.local --8<---cut here---end--->8--- The error is: , | > cat(IFN.raw) | 'org_babel_R_eoe' | Error in cat(IFN.raw) : object 'IFN.raw' not found | > [1] "org_babel_R_eoe" | > ` In other words, the second code block is evaluated, but the second one not. If I remove the :evel: property *in the previous* tree, it works as expected. But in the main document, I have code in there which I do not want to have evaluated. This has been introduced within the previous week, if I am not mistaken. Cheers, Rainer -- Rainer M. Krug PGP: 0x0F52F982 smime.p7s Description: S/MIME cryptographic signature
Re: [O] Prepare release 8.2.6
Hi Bastien, I sent a mail "[PATCH] ob-scheme.el: Fix scheme code blocks execution error in batch mode" to the list yesterday, but I don't see it at http://news.gmane.org/gmane.emacs.orgmode, so here I sent it to you again: The bug: write file ~/scheme-test.org with the content below: ---8<-- #+BEGIN_SRC scheme :exports results :results output raw (display "Hello Scheme in OrgMode") #+END_SRC ---8<-- and run: emacs --batch --eval='(load "~/.emacs.d/init.el")' ~/scheme-test.org -f org-html-export-to-html you will find the bug: `org-babel-scheme-execute-with-geiser' uses `current-message' to get the results of scheme code blocks, but `current-message' always returns nil in batch mode, and the attached patch fixes this. Please consider to apply it, thanks. On Thu, Apr 3, 2014 at 3:53 PM, Bastien wrote: > Hi all, > > I'll spend a few hours this afternoon chasing the last > bugs in maint for Org 8.2.6. This release will then be > merged into the emacs-24 branch, which first pretest is > to be released very soon now. > > If you have outstanding bugs, please point at them. > > As usual, thanks in advance for your help, > > PS: gmane.org seems to be down since April, 1st, so I > could not follow the discussions since that time. > > -- > Bastien > > -- -- KDr2, http://kdr2.com From cebf9fc4fe09ab22fd31ff8e5606d0f680c121e9 Mon Sep 17 00:00:00 2001 From: KDr2 Date: Wed, 2 Apr 2014 10:30:38 +0800 Subject: [PATCH] ob-scheme.el: Fix scheme code blocks execution error in batch mode * lisp/ob-scheme.el (org-babel-scheme-capture-current-message, org-babel-scheme-execute-with-geiser): Capture scheme code results via current-message both in interactive mode and noninteractive mode. `org-babel-scheme-execute-with-geiser' uses `current-message' to get the results of scheme code blocks, but `current-message' always returns nil in batch mode, and this patch fixes this. Modified from a patch proposal by KDr2 --- lisp/ob-scheme.el | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el index b7117e9..3b7ceb2 100644 --- a/lisp/ob-scheme.el +++ b/lisp/ob-scheme.el @@ -118,6 +118,17 @@ org-babel-scheme-execute-with-geiser will use a temporary session." (name result)) +(defmacro org-babel-scheme-capture-current-message (&rest body) + "Capture current message in both interactive and noninteractive mode" + `(if noninteractive + (let ((current-message nil)) + (flet ((message (fmt &rest args) (setq current-message (apply #'format fmt args + ,@body + current-message)) + (progn + ,@body + (current-message + (defun org-babel-scheme-execute-with-geiser (code output impl repl) "Execute code in specified REPL. If the REPL doesn't exist, create it using the given scheme implementation. @@ -142,10 +153,11 @@ is true; otherwise returns the last value." (current-buffer) (setq geiser-repl--repl repl-buffer) (setq geiser-impl--implementation nil) - (geiser-eval-region (point-min) (point-max)) + (setq result (org-babel-scheme-capture-current-message + (geiser-eval-region (point-min) (point-max (setq result - (if (equal (substring (current-message) 0 3) "=> ") - (replace-regexp-in-string "^=> " "" (current-message)) + (if (and (stringp result) (equal (substring result 0 3) "=> ")) + (replace-regexp-in-string "^=> " "" result) "\"An error occurred.\"")) (when (not repl) (save-current-buffer (set-buffer repl-buffer) -- 1.9.1
Re: [O] Prepare release 8.2.6
Hi Bastien, Bastien writes: > Hi all, > > I'll spend a few hours this afternoon chasing the last > bugs in maint for Org 8.2.6. This release will then be > merged into the emacs-24 branch, which first pretest is > to be released very soon now. > > If you have outstanding bugs, please point at them. I don't know if this qualifies as a bug, but I have not been able to get around this: http://article.gmane.org/gmane.emacs.orgmode/84472 I just checked out out the maint branch, and I see the same problematic behavior as I get with ELPA. Things work correctly in the master branch. Alan
[O] Prepare release 8.2.6
Hi all, I'll spend a few hours this afternoon chasing the last bugs in maint for Org 8.2.6. This release will then be merged into the emacs-24 branch, which first pretest is to be released very soon now. If you have outstanding bugs, please point at them. As usual, thanks in advance for your help, PS: gmane.org seems to be down since April, 1st, so I could not follow the discussions since that time. -- Bastien
