Re: [O] [PATCH] ob-core: Fix indented cached result returning nil
On 24 May 2015, at 11:53, Bjarte Johansen bjarte.johan...@gmail.com wrote: On 24 May 2015, at 11:49, Bjarte Johansen bjarte.johan...@gmail.com wrote: On 23 May 2015, at 21:50, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Bjarte Johansen bjarte.johan...@gmail.com writes: Fix a problem where a source block would return nil oif the result was cached and it was indented. Thank you. However, the test you provide fails. I suggest to create test.txt in `temporary-file-directory' instead of `default-directory'. Regards, Ah, it was not supposed to actually run the code in the source block; only get the cached result. I might know an easier test of it. I’ll send a revised version later. Actually, I saw now that it should be (message “test.txt”), notice the added extension. The hash is also therefore most likely wrong. I will fix it. No, this was wrong. I have a more robust fix and do as you suggest. Create the file in temporary-file-directory and run the execution of the source block twice to get the cache. This way, if org-mode changes its hashing function later, the test will still work. Sending the patch shortly. Regards, Bjarte
[O] [PATCH] ob-core: Fix indented cached result returning nil
Fix a problem where a source block would return nil oif the result was cached and it was indented. * lisp/ob-core.el (org-babel-execute-src-block): Move point to the the first character of the result instead of the beginning of the line. * testing/lisp/test-ob.el (test-org-babel/indented-cached-org-bracket-link): Added test to to see if the indented cached result returns what it should return. --- lisp/ob-core.el | 3 ++- testing/lisp/test-ob.el | 16 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index d25bb7c..9575096 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -653,7 +653,8 @@ block. (cache-current-p (save-excursion ;; return cached result (goto-char (org-babel-where-is-src-block-result nil info)) - (end-of-line 1) (forward-char 1) + (end-of-line 1) + (forward-char (1+ (current-indentation))) (let ((result (org-babel-read-result))) (message (replace-regexp-in-string % %% (format %S result))) result))) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index f52ff24..83b4d00 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -20,6 +20,22 @@ ;;; Code: +(ert-deftest test-org-babel/indented-cached-org-bracket-link () + When the result of a source block is a cached indented link it +should still return the link. + (should + (let ((default-directory temporary-file-directory)) + (org-test-with-temp-text + +* Test + #+pointBEGIN_SRC emacs-lisp :file test.txt :cache yes +(message \test\) + #+END_SRC + ;; Execute twice as the first time creates the cache. + (org-babel-execute-src-block) + (string= (concat default-directory test.txt) + (org-babel-execute-src-block)) + (ert-deftest test-org-babel/multi-line-header-regexp () (should(equal ^[ \t]*#\\+headers?:[ \t]*\\([^\n]*\\)$ org-babel-multi-line-header-regexp)) -- 2.3.2 (Apple Git-55)
[O] New maintainance team
Hi all, thanks for the quick answers on helping me with the maintaince. Here is the new maintainance team: Kyle Meyer will watch Emacs development and merge changes there into the local Org repository. Elwood151 will be the contact for people who want to contribute and have their keys added to the server. Robert Klein will help maintaining the orgmode.org server and keep an eye on the Worg publishing process. Rasmus will handle the merge from Org into Emacs after each release. I will continue to release Org for now. THANKS a lot to everyone! I'm really glad we can move forward like this. -- Bastien
Re: [O] New maintainance team
Christian Moe m...@christianmoe.com writes: Thanks and a big hand of applause to all of you, and to Nicolas, for making Org-mode keep on rockin'. Seconded - from the archetypal clueless user! with best wishes Glyn
Re: [O] [PATCH] ob-core: Fix indented cached result returning nil
On 23 May 2015, at 21:50, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Bjarte Johansen bjarte.johan...@gmail.com writes: Fix a problem where a source block would return nil oif the result was cached and it was indented. Thank you. However, the test you provide fails. I suggest to create test.txt in `temporary-file-directory' instead of `default-directory'. Regards, Ah, it was not supposed to actually run the code in the source block; only get the cached result. I might know an easier test of it. I’ll send a revised version later.
Re: [O] [bug] orgstruct++-mode breaks backward-sentence
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
I think the best we can do is to hijack M-a/M-e when `orgstruct-mode' is
used. `orgtbl-mode' already does it actually.
I tried to do this, but somehow I cannot get the magic that builds
orgstruct-mode-map to recognize org-{forward,backward}-sentence. I think
it has to do with the Meta. Other Meta bindings use ?\e and the numeric
value that is picked up for \M-a is pretty large... Sometimes I managed
to get org-backward-sentence in the orgstruct-mode-map, but it just wans't
picked up.
Any hints would be appreciated.
Rasmus
My test:
(progn
(add-to-list 'load-path ~/src/code/org-mode/lisp)
(require 'org)
(require 'cl)
(mapcar (lambda (mode)
(with-temp-buffer
(insert * test
- aaa baa
zaa)
(text-mode)
(funcall mode)
(call-interactively (or (local-key-binding \M-a)
(global-key-binding \M-a)))
(cons (point) (or (local-key-binding \M-a)
(global-key-binding \M-a)
'(text-mode turn-on-orgstruct++ org-mode)))
--
Bang bang
Re: [O] Help needed on delegating some maintainance tasks
Hi Robert, Robert Klein rokl...@roklein.de writes: I'd like to help with 3 but would need an introduction. Great, thanks. I'll send a summary on the list soon. -- Bastien
Re: [O] New maintainance team
Thanks and a big hand of applause to all of you, and to Nicolas, for making Org-mode keep on rockin'. Yours, Christian Bastien writes: Hi all, thanks for the quick answers on helping me with the maintaince. Here is the new maintainance team: Kyle Meyer will watch Emacs development and merge changes there into the local Org repository. Elwood151 will be the contact for people who want to contribute and have their keys added to the server. Robert Klein will help maintaining the orgmode.org server and keep an eye on the Worg publishing process. Rasmus will handle the merge from Org into Emacs after each release. I will continue to release Org for now. THANKS a lot to everyone! I'm really glad we can move forward like this.
Re: [O] Help needed on delegating some maintainance tasks
Von: Rasmus ras...@gmx.us Datum: Sat, 23 May 2015 11:31:57 +0200 An: emacs-orgmode@gnu.org Betreff: Re: [O] Help needed on delegating some maintainance tasks Hi, Bastien b...@gnu.org writes: 1. Watching the emacs-diffs mailing list and backport changes on Org in the local Org repository (2 hours per month). 2. Adding public keys on the orgmode.org server for org-mode and worg contributers (1 hour per month). 3. Maintaining the orgmode.org server and taking care of errors when updating Worg (1 hour per month). 4. Merging the last stable release into Emacs repository. (1 hour every release). 5. Releasing Org (.5 hour every release). I can help with 2, 4 *OR* 5 as you prefer. My git skillz are limited. Rasmus As my git skills are near to zero, I could only help with #2 (after some short introduction). Kind regards Martin
Re: [O] [PATCH] ob-core: Fix indented cached result returning nil
On 24 May 2015, at 11:49, Bjarte Johansen bjarte.johan...@gmail.com wrote: On 23 May 2015, at 21:50, Nicolas Goaziou m...@nicolasgoaziou.fr wrote: Bjarte Johansen bjarte.johan...@gmail.com writes: Fix a problem where a source block would return nil oif the result was cached and it was indented. Thank you. However, the test you provide fails. I suggest to create test.txt in `temporary-file-directory' instead of `default-directory'. Regards, Ah, it was not supposed to actually run the code in the source block; only get the cached result. I might know an easier test of it. I’ll send a revised version later. Actually, I saw now that it should be (message “test.txt”), notice the added extension. The hash is also therefore most likely wrong. I will fix it.
Re: [O] [RFC] Org linting library
Rainer M Krug rai...@krugs.de writes: Concerning ignoring: it would be nice to dynamically exclude certain types of messages - i.e. hiding them from the results of the linting. I don't think this is possible at the moment? I have literally about 100 names with a colon - so these messages are overshadowing the really important ones. Done. Now, h hides reports from checker and point. i ignores them altogether, which means they do not appear on subsequent refreshes. Another question: When duplicate names are detected, would it be possible to specify both (or more) line numbers in the warning? THis would make finding them much easier. Done. Regards,
Re: [O] Treat custom environment as verbatim on export
Rasmus ras...@gmx.us writes:
It's a special block, so e.g. org-latex-special-block. But contents is
already transcoded by the time in arrives to e.g. org-latex-special-block.
To the extend this should be fixed, one way would be to allow a raw option
to special blocks (also needed for e.g. #+{begin,end}_equation) and have
babel insert it as needed. I don't know how easy this is.
I don't think a :raw option for special blocks is worth implementing.
There are two types or raw contents: protected raw (i.e., verbatim
contents) and export-specific raw (i.e., target language code). For
the former, we already have example blocks (or fixed-width areas) and
for the latter, export blocks.
A third category exists, multi-language raw, in which, I think, only
the most trivial cases (those you never really need in practice) would
fit.
The OP wants special protected raw for LaTeX back-end. We could
provide a special attribute for this, e.g.,
#+ATTR_LATEX: :environment my-verbatim
#+BEGIN_EXAMPLE
... stuff...
#+END_EXAMPLE
But this is really only a shortcut for
#+BEGIN_my-verbatim
#+BEGIN_LATEX
stuff
#+END_LATEX
#+END_my-verbatim
WDYT?
Regards,
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: #+header: :session #+BEGIN_SRC R :results table :exports results x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) #+END_SRC #+results: | One: | | Two: | hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Treat custom environment as verbatim on export
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Rasmus ras...@gmx.us writes:
It's a special block, so e.g. org-latex-special-block. But contents is
already transcoded by the time in arrives to e.g. org-latex-special-block.
To the extend this should be fixed, one way would be to allow a raw option
to special blocks (also needed for e.g. #+{begin,end}_equation) and have
babel insert it as needed. I don't know how easy this is.
I don't think a :raw option for special blocks is worth implementing.
There are two types or raw contents: protected raw (i.e., verbatim
contents) and export-specific raw (i.e., target language code). For
the former, we already have example blocks (or fixed-width areas) and
for the latter, export blocks.
A third category exists, multi-language raw, in which, I think, only
the most trivial cases (those you never really need in practice) would
fit.
The OP wants special protected raw for LaTeX back-end. We could
provide a special attribute for this, e.g.,
#+ATTR_LATEX: :environment my-verbatim
#+BEGIN_EXAMPLE
... stuff...
#+END_EXAMPLE
But this is really only a shortcut for
#+BEGIN_my-verbatim
#+BEGIN_LATEX
stuff
#+END_LATEX
#+END_my-verbatim
WDYT?
If the end goal is
#+BEGIN_my-verbatim
#+BEGIN_LATEX
stuff
#+END_LATEX
#+END_my-verbatim
Then I think it should be producible with babel via
#+begin_src Emacs-lisp :wrap my-verbatim :results latex
stuff
#+end_src
However,
#+ATTR_LATEX: :environment my-verbatim
#+BEGIN_EXAMPLE
... stuff...
#+END_EXAMPLE
Is more general since it also produce sensible output in other backends.
Thus, I think passing attr arguments to example blocks may be
preferable... Though *if* you are only going for latex export, :wrap
my-verbatim :results latex seems more convenient to me.
Rasmus
--
This message is brought to you by the department of redundant departments
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Formatted text (bold/italics) in agenda view
Ali Tofigh alix.tof...@gmail.com writes: I've noticed that formatting of text, e.g., using *text* or /text/, does not show up in agenda view. Is there a way of enabling this? AFAIK, it is not possible at the moment. It would required special per-line fontification set-up, which is not implemented in org-agenda.el. Regards, -- Nicolas Goaziou
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. #+header: :session #+BEGIN_SRC R :results table :exports results x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) #+END_SRC #+results: | One: | | Two: | hth, Tom signature.asc Description: PGP signature
Re: [O] [RFC] Org linting library
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Rainer M Krug rai...@krugs.de writes: Concerning ignoring: it would be nice to dynamically exclude certain types of messages - i.e. hiding them from the results of the linting. I don't think this is possible at the moment? I have literally about 100 names with a colon - so these messages are overshadowing the really important ones. Done. Now, h hides reports from checker and point. i ignores them altogether, which means they do not appear on subsequent refreshes. Sounds perfect - am really looking forward to trying it out on Tuesday. Another question: When duplicate names are detected, would it be possible to specify both (or more) line numbers in the warning? THis would make finding them much easier. Done. Perfect. Cheers, Rainer Regards, -- 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 signature.asc Description: PGP signature
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-24 Sun 10:09, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: On 2015-05-24 Sun 08:36, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Also expected due to :rownames yes :colnames yes. Without those two header arguments: Consider this example: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes v - c(a, b) #+END_SRC #+RESULTS: | | x | |---+---| | 1 | a | | 2 | b | Where is the “x” coming from? In R, colnames(v) gives me NULL. rownames(v) is also NULL. You are asking Org mode to produce a table with row and column names from a vector, which lacks rows and columns. What behavior do you expect? Almost anything is better than Org showing me values that do not exist in the original data. Empty cells for row and columns names are probably the best solution because that would be faithful to the data and to the settings (:rownames yes :colnames yes). Titus signature.asc Description: PGP signature
Re: [O] Treat custom environment as verbatim on export
On Sun, 24 May 2015, Nicolas Goaziou wrote:
Rasmus ras...@gmx.us writes:
It's a special block, so e.g. org-latex-special-block. But contents is
already transcoded by the time in arrives to e.g. org-latex-special-block.
To the extend this should be fixed, one way would be to allow a raw option
to special blocks (also needed for e.g. #+{begin,end}_equation) and have
babel insert it as needed. I don't know how easy this is.
I don't think a :raw option for special blocks is worth implementing.
There are two types or raw contents: protected raw (i.e., verbatim
contents) and export-specific raw (i.e., target language code). For
the former, we already have example blocks (or fixed-width areas) and
for the latter, export blocks.
A third category exists, multi-language raw, in which, I think, only
the most trivial cases (those you never really need in practice) would
fit.
The OP wants special protected raw for LaTeX back-end. We could
provide a special attribute for this, e.g.,
#+ATTR_LATEX: :environment my-verbatim
#+BEGIN_EXAMPLE
... stuff...
#+END_EXAMPLE
But this is really only a shortcut for
#+BEGIN_my-verbatim
#+BEGIN_LATEX
stuff
#+END_LATEX
#+END_my-verbatim
WDYT?
Currently, :wrap allows this:
#+begin_src emacs-lisp :wrap src latex :wrap my-verbatim :exports results
stuff\nmore stuff
#+end_src
which exports as
,
| \begin{my-verbatim}
| stuff
| more stuff
| \end{my-verbatim}
`
which is what was wanted (courtesy of ob-latex.el).
Is that enough?
HTH,
Chuck
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
Titus von der Malsburg malsb...@posteo.de writes: I’m exporting the following document to LaTeX #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) #+END_SRC and expect a table with the following layout: a b One: 1 3 Two: 2 4 Instead I got this: x 1 One: 2 Two: You got the result of rownames(x), which is expected. The table you expect is given by the following code: #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) x #+END_SRC #+results: | | a | b | |--+---+---| | One: | 1 | 3 | | Two: | 2 | 4 | All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Bug: Org export to latex produces incorrect table [8.3beta (release_8.3beta-1157-g8ddb84 @ /home/malsburg/usr/share/emacs/site-lisp/org/)]
On 2015-05-24 Sun 00:01, Thomas S. Dye wrote: Titus von der Malsburg malsb...@posteo.de writes: I’m exporting the following document to LaTeX #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) #+END_SRC and expect a table with the following layout: a b One: 1 3 Two: 2 4 Instead I got this: x 1 One: 2 Two: You got the result of rownames(x), which is expected. The table you expect is given by the following code: Ah, I see, thanks. Although the results is still somewhat unexpected. c(One:, Two:) doesn’t have rownames and colnames. So org apparently made them up when generating the table. Titus #+BEGIN_SRC R :results table :exports results :colnames yes :rownames yes x - data.frame(a=1:2, b=3:4) rownames(x) - c(One:, Two:) x #+END_SRC #+results: | | a | b | |--+---+---| | One: | 1 | 3 | | Two: | 2 | 4 | All the best, Tom signature.asc Description: PGP signature
