[O] Nested calls in babel
Hi all, I am being unable to make nested calls work. Here is a minimal snippet: --8<---cut here---start->8--- #+NAME: foo #+BEGIN_SRC emacs-lisp "foo" #+END_SRC #+NAME: bar #+CALL: foo() #+RESULTS: bar : foo #+CALL: bar() #+RESULTS: : nil --8<---cut here---end--->8--- Why does the last call (to bar) return nil instead of the result of bar (which is "foo")? Actually, if I remove foo altogether, executing "bar" block gives an error, but executing the last call to "bar" still works (and still returns nil). Are nested calls supported at all? Thanks, Carlos -- Carlos
Re: [O] send block evaluation results to specified buffer
On Wed, Sep 11, 2019 at 5:44 PM Arthur A. Gleckler wrote: > When a :buffer is specified, output goes to that buffer, which is erased > first, e.g.: > > #+begin_src sh :results buffer > echo foo > #+end_src > Sorry, the first example was supposed to be: #+begin_src sh :results buffer :buffer *foo* echo foo #+end_src
[O] [PATCHATTACHED] Fixing org-store-link for eshell
Hello all, Thank you for supporting and maintaining org mode. I wanted to use org-store-link for eshell, but it failed. Looked like dired-directory was nil, I fixed it by calling (eshell/pwd) to get pwd. I tested with and without TRAMP, works like a charm. The patch did not create new test case failures, but for master branch on my machine I saw 6 test case failure (not related to patch). 6 unexpected results: FAILED ob-sed-test/cmd-line-header-argument FAILED ob-shell/bash-uses-assoc-arrays FAILED ob-tangle/jump-to-org FAILED test-ob-shell/session FAILED test-org-attach/dir FAILED test-org-table/sort-lines I will try investigate and address them in another patch. Thanks, -Abhishek 0001-ol-eshell.el-Fix-org-store-link-for-eshell.patch Description: Binary data
[O] [PATCH] org: Prevent loss of `re-search-forward' results
Hello! I got burned by this issue while implementing a custom link handler. 0001-org-Prevent-loss-of-re-search-forward-results.patch Description: Binary data
Re: [O] Org mode pollutes the narrow-map
Great, thanks! On Fri, Aug 23, 2019, 3:40 AM Nicolas Goaziou wrote: > Hello, > > Omar Antolín Camarena writes: > > > Hello everyone, > > > > Does it seems a little rude that Org mode binds its own narrowing > commands in the global narrow-map? > > > > You can find this in org.el starting at line 19018: > > > > #+begin_src emacs-lisp > > Narrow map > > (org-defkey narrow-map "s" #'org-narrow-to-subtree) > > (org-defkey narrow-map "b" #'org-narrow-to-block) > > (org-defkey narrow-map "e" #'org-narrow-to-element) > > #+end_src > > > > I don't need or really want those commands bound in non-org buffers. > > I think it would be better to bind them (to C-x n s, C-x n b and C-x > > n e) in org-mode-map. This is the approach taken by AUCTeX, for > > example. (To be clear, I mean AUCTeX has some narrowing commands and > > it binds them to C-x n e and C-x n g in its own keymaps.) > > It sounds reasonable. I changed the bindings in master. Thank you. > > Regards, > > -- > Nicolas Goaziou >
Re: [O] Best practice for providing an Org-based application?
* Marcin Borkowski [2019-09-11 09:17]: > This reminds me of this: > https://www.joelonsoftware.com/2012/01/06/how-trello-is-different/ > > I just had a minor enlightenment why Org-mode is so successful (within > its niche, of course). It implements a bunch of very general data > structures - a tree, a table, a dictionary - and a few slightly more > specific - a clock table, TODOs/tags, markup... Exactly, it is well integrated. The tree is extremely useful. And maybe it is popular because of... because of propaganda. There is the manual and few demonstrations and then people get the "Aha" moment sooner. THere are other hierarchical note editors. Org mode I have discovered very late and I remember using `hnb' the hierarchical notebook program that was written in curses, look here: http://hnb.sourceforge.net/Screen-shots/ since its inception. Yet such does not have good propaganda and it not implemented in the Emacs editor. There is also Cherrytree https://www.giuspen.com/cherrytree/ beautiul application for note taking, just missing few features from Org mode. Yet the beauty of it all is that Org mode has the simple text as its foundation and no special format. Jean
Re: [O] Scheduling in a narrowed subtree: Bug?
On Mon, Sep 09 2019, Michaël Cadilhac wrote: > Is this the expected behavior? > > 1. Create an empty org file > 2. Insert > * Test > * Test 2 > 3. With the cursor at Test, hit C-x n s to narrow the view to the Test subtree > 4. Hit C-c C-s to schedule the line at any date. > > As a result, the SCHEDULED keyword is _not_ included in the narrow view, and > inserting things after the Test heading > moves the SCHEDULED keyword away from its second-line position. This is likely related to https://lists.gnu.org/archive/html/emacs-orgmode/2019-07/msg00087.html Regards, Gustavo.
[O] send block evaluation results to specified buffer
Attached is a patch to allow one to specify that results from executing a block should go to a specific buffer. When a :buffer is specified, output goes to that buffer, which is erased first, e.g.: #+begin_src sh :results buffer echo foo #+end_src When no :buffer is specified, buffer *org results* is used, e.g.: #+begin_src sh :results buffer echo foo #+end_src I've tried to follow the conventions for contributions to Org mode, buf if I've missed something, please let me know. (I'm happy to sign the FSF paperwork.) Thank you for Org mode! From 929b1ae2f908b39de529384a5854fc5b8d035282 Mon Sep 17 00:00:00 2001 From: "Arthur A. Gleckler" Date: Wed, 11 Sep 2019 17:03:33 -0700 Subject: [PATCH] ob-core.el: block result output to buffer * lisp/ob-core.el (org-babel-execute-src-block): Support buffers. Allow specifying that results from executing a block should go to a buffer. When a :buffer is specified, output goes to that buffer, which is erased first, e.g.: #+begin_src sh :results buffer echo foo #+end_src When no :buffer is specified, buffer "*org results*" is used, e.g.: #+begin_src sh :results buffer echo foo #+end_src Also fixed typo: "it's" vs. "its". --- doc/org-manual.org | 8 lisp/ob-core.el| 44 2 files changed, 36 insertions(+), 16 deletions(-) diff --git a/doc/org-manual.org b/doc/org-manual.org index f2f059e77..8e2715eeb 100644 --- a/doc/org-manual.org +++ b/doc/org-manual.org @@ -17333,6 +17333,14 @@ default behavior is to automatically determine the result type. TAB-delimited output. You can choose a different separator with the =sep= header argument. +- =buffer= :: + + Save results to a specific buffer. Erase the buffer, save the + results of execution of the code block to that buffer, then display + it. The buffer name may be specified in the =:buffer= header + argument. If it's not specified, the buffer =*org results*= is + used. + *** Format :PROPERTIES: :UNNUMBERED: notoc diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 97ec18fd1..1537b4363 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -707,22 +707,33 @@ block." (not (listp r))) (list (list r)) r))) - (let ((file (and (member "file" result-params) + (let ((buffer (and (member "buffer" result-params) + (get-buffer-create + (or (cdr (assq :buffer params)) + "*org result*" + (file (and (member "file" result-params) (cdr (assq :file params) ;; If non-empty result and :file then write to :file. - (when file - ;; If `:results' are special types like `link' or - ;; `graphics', don't write result to `:file'. Only - ;; insert a link to `:file'. - (when (and result - (not (or (member "link" result-params) - (member "graphics" result-params - (with-temp-file file - (insert (org-babel-format-result - result - (cdr (assq :sep params)) - (setq result file)) - ;; Possibly perform post process provided its + (cond (buffer + (with-current-buffer buffer + (erase-buffer) + (insert (org-babel-format-result + result + (cdr (assq :sep params) + (display-buffer buffer)) + (file + ;; If `:results' are special types like `link' or + ;; `graphics', don't write result to `:file'. Only + ;; insert a link to `:file'. + (when (and result + (not (or (member "link" result-params) + (member "graphics" result-params + (with-temp-file file + (insert (org-babel-format-result +result +(cdr (assq :sep params)) + (setq result file))) + ;; Possibly perform post process provided it's ;; appropriate. Dynamically bind "*this*" to the ;; actual results of the block. (let ((post (cdr (assq :post params @@ -735,8 +746,9 @@ block." (setq result (org-babel-ref-resolve post)) (when file (setq result-params (remove "file" result-params)) - (org-babel-insert-result - result result-params info new-hash lang))) + (unless buffer + (org-babel-insert-result + result result-params info new-hash lang (run-hooks 'org-babel-after-execute-hook) result))) -- 2.20.1
Re: [O] Cannot display local images with orgmode under macOS
Hi, > * The problem > > Orgmode under macOS cannot display local images correctly, but it can > display internet images > without problem. > > I tried both emacs-mac and emacs-plus, they both have this image problem. > But emacs under > ArchLinux don’t have this problem. > > [[file:xxx.png]] cannot be displayed even > the file exists. > [[./xxx.png]] cannot be displayed even > the file exists. > [[http://example.org/xxx.png]] can be displayed if the link exists. > > Emacs can display any images with C-x C-f xxx.png. The problem happens > only with orgmode. > > * The reason > > After bisecting org-mode source code I found out that this commit causes > the problem: > > > https://code.orgmode.org/bzg/org-mode/commit/48da60f47a77f4b99b4160fa620f258896ff4da3 > > Reverting to previous commit fixes the problem. Gaa! Looks like I did this. With the commit one should be able to see inline images also in the case when Emacs has been build without imagemagick support, at least for newer Emacsens in the 27 line. Unfortunately I don't have a Mac and cannot examine the behavior you describe AFAICS. Hopefully a Org community member with access to a Mac can have a look. Thanks for reporting, -- Marco
[O] [PATCH] ox-latex.el: Extend :placement attribute to source blocks
* lisp/ox-latex.el (org-latex-src-block): Extend :placement attribute
to source blocks when the minted package is used.
TINYCHANGE
---
lisp/ox-latex.el | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 1f1be240a..77aac78f4 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2957,21 +2957,23 @@ contextual information."
;; Case 3. Use minted package.
((eq listings 'minted)
(let* ((caption-str (org-latex--caption/label-string src-block info))
+ (placement (or (org-unbracket-string "[" "]" (plist-get
attributes :placement))
+ (plist-get info :latex-default-figure-position)))
(float-env
(cond
((string= "multicolumn" float)
(format "\\begin{listing*}[%s]\n%s%%s\n%s\\end{listing*}"
- (plist-get info :latex-default-figure-position)
+ placement
(if caption-above-p caption-str "")
(if caption-above-p "" caption-str)))
(caption
(format "\\begin{listing}[%s]\n%s%%s\n%s\\end{listing}"
- (plist-get info :latex-default-figure-position)
+ placement
(if caption-above-p caption-str "")
(if caption-above-p "" caption-str)))
((string= "t" float)
(concat (format "\\begin{listing}[%s]\n"
- (plist-get info
:latex-default-figure-position))
+ placement)
"%s\n\\end{listing}"))
(t "%s")))
(options (plist-get info :latex-minted-options))
--
2.23.0
Re: [O] Cannot display local images with orgmode under macOS
> On Sep 12, 2019, at 5:48 AM, Marco Wahl wrote: > > Hi, > >> * The problem >> >>Orgmode under macOS cannot display local images correctly, but it can >> display internet images >> without problem. >> >>I tried both emacs-mac and emacs-plus, they both have this image problem. >> But emacs under >> ArchLinux don’t have this problem. >> >>[[file:xxx.png]] cannot be displayed even >> the file exists. >>[[./xxx.png]] cannot be displayed even >> the file exists. >>[[http://example.org/xxx.png]] can be displayed if the link exists. >> >>Emacs can display any images with C-x C-f xxx.png. The problem happens >> only with orgmode. >> >> * The reason >> >>After bisecting org-mode source code I found out that this commit causes >> the problem: >> >> >> https://code.orgmode.org/bzg/org-mode/commit/48da60f47a77f4b99b4160fa620f258896ff4da3 >> >>Reverting to previous commit fixes the problem. > > Gaa! Looks like I did this. With the commit one should be able to see > inline images also in the case when Emacs has been build without > imagemagick support, at least for newer Emacsens in the 27 line. > > Unfortunately I don't have a Mac and cannot examine the behavior you > describe AFAICS. > > Hopefully a Org community member with access to a Mac can have a look. > > I just updated org, I can see the offending commit. After refreshing, I have no problems toggling display of inline images. I have imagemagick and dvipng installed. MacOS 10.14.6, Emacs 26.1, org release_9.2.6-534-g6f32e7 Is there anything else I can tell you? HTH, Chuck
Re: [O] Nested calls in babel
Your example works for me. viz, the call to bar returns "foo" (not nil). MacOS 10.14.6, Emacs 26.1, org release_9.2.6-534-g6f32e7 HTH, Chuck > On Sep 10, 2019, at 12:57 AM, Carlos Sánchez de La Lama > wrote: > > Hi all, > > I am being unable to make nested calls work. Here is a minimal snippet: > > --8<---cut here---start->8--- > #+NAME: foo > #+BEGIN_SRC emacs-lisp > "foo" > #+END_SRC > > #+NAME: bar > #+CALL: foo() > > #+RESULTS: bar > : foo > > #+CALL: bar() > > #+RESULTS: > : nil > --8<---cut here---end--->8--- > > Why does the last call (to bar) return nil instead of the result of bar > (which is "foo")? Actually, if I remove foo altogether, executing "bar" > block gives an error, but executing the last call to "bar" still works > (and still returns nil). > > Are nested calls supported at all? > > Thanks, > > Carlos > > -- > Carlos > >
Re: [O] ANN: org-ql agenda block support
Great overview, thanks a lot. So I give it a try and completely fell in love. On my data set it is visibly faster then org-agenda. I also wrote a lot of code around org-agenda over the years to support my sometimes awkward needs. And now I just threw all this ugly code away! That was very emotional moment for me, very good job, kind sir. Adam Porter writes: > Mikhail Skorzhinskii writes: > > > Adam Porter writes: > > > However, the org-ql-block version runs in about 1/5th the time (0.7 > > > seconds compared to 3.45 seconds on my collection of org-agenda-files). > > > > For some reason I thought that on average org-ql package is working > > slower then native org-agenda searches. Probably because there are more > > control and interface is much more simpler and cleaner and nothing > > comes free of charge. That sort of thing. :-) > > Well, it might also be because it used to be generally slower, and I > tried to be clear about that whenever I mentioned it. :) But I've > applied a lot of optimizations to it over the past few months, so it's > generally pretty fast now, sometimes much faster. It's hard to make a > direct comparison in some cases, depending on the complexity of the > query. I plan to continue optimizing it as I'm able, so hopefully it > will continue improving. > > > I am really glad that I was mistaken. Care to drop a few thoughts on why > > this is the case? This is applicable only for ql-block or other org-ql > > functions are a bit faster too? > > Well, it's a completely different implementation. It has two main > features which attempt to make it fast: it uses regexp searches across > buffers as much as possible, similar to org-agenda.el but in a more > flexible way (though there's still room for improvement here, especially > with complex queries); and it caches results keyed on the query, buffer, > and narrowing (cached results are discarded when a buffer is modified), > which avoids re-running the same queries for unmodified buffers. Oh, > and it also byte-compiles query predicates and action functions to eke > out a bit more speed. > > And in general, I run benchmarks and try to improve performance when > possible; you can see some of the benchmark results in the notes.org > file in the repo (not all of which are up-to-date with current org-ql > code). > > org-ql-block is just a way to make use of the results returned by org-ql > queries; other ways include org-ql-agenda, org-ql-search, and of course > you can use the raw results however you like, including calling whatever > :action function you like at matching entries, to return whatever kind > of data you need, or even perform actions directly on entries. > > In other words, the querying code is separate from the display-related > code, so all org-ql-block, org-ql-agenda, org-ql-search, etc. do is > format results from org-ql queries and display them. > > Upcoming features include an org-ql-sparse-tree command, like > org-sparse-tree but using org-ql queries; recursive queries; and > probably a timeline view like I recently posted about. > > Please let me know if you have any feedback!
Re: [O] Cannot display local images with orgmode under macOS
Running Emacs 26.3 on macOS 10.14.6 with latest org and I have no problems displaying images in org mode. I have imagemagick installed and am using railwaycat's mac-port via homebrew. Tim Berry, Charles writes: >> On Sep 12, 2019, at 5:48 AM, Marco Wahl wrote: >> >> Hi, >> >>> * The problem >>> >>>Orgmode under macOS cannot display local images correctly, but it can >>> display internet images >>> without problem. >>> >>>I tried both emacs-mac and emacs-plus, they both have this image >>> problem. But emacs under >>> ArchLinux don’t have this problem. >>> >>>[[file:xxx.png]] cannot be displayed even >>> the file exists. >>>[[./xxx.png]] cannot be displayed even >>> the file exists. >>>[[http://example.org/xxx.png]] can be displayed if the link exists. >>> >>>Emacs can display any images with C-x C-f xxx.png. The problem happens >>> only with orgmode. >>> >>> * The reason >>> >>>After bisecting org-mode source code I found out that this commit causes >>> the problem: >>> >>> >>> https://code.orgmode.org/bzg/org-mode/commit/48da60f47a77f4b99b4160fa620f258896ff4da3 >>> >>>Reverting to previous commit fixes the problem. >> >> Gaa! Looks like I did this. With the commit one should be able to see >> inline images also in the case when Emacs has been build without >> imagemagick support, at least for newer Emacsens in the 27 line. >> >> Unfortunately I don't have a Mac and cannot examine the behavior you >> describe AFAICS. >> >> Hopefully a Org community member with access to a Mac can have a look. >> >> > > > I just updated org, I can see the offending commit. > > After refreshing, I have no problems toggling display of inline images. > > I have imagemagick and dvipng installed. > > MacOS 10.14.6, Emacs 26.1, org release_9.2.6-534-g6f32e7 > > Is there anything else I can tell you? > > HTH, > > Chuck -- Tim Cross
