[O] How to add tblname from ob-shell fragments?
Hi, I'm trying to solve a problem with an ob-shell fragment. I want to emit a table which other blocks are going to consume. As script takes a while I don't want to dynamically call it when doing additional work with the data. In fact in my real example I use ob-async's :async so it can run and collect the data in the background. Is there any way to get the results to emit a tblname with the result? -- Alex Bennée
[O] Advice for debugging org-export
Hi, I find debugging my exporters for org-mode a real pain. Consider the following: #+name: get-task-list-as-exported-text #+begin_src emacs-lisp :exports code (defun my-filter-out-done-lines (s backend info) "Filter out lines ending in :done" (apply 'concat (--remove (s-matches? (rx ":done" (zero-or-more blank) eol) it) (s-slice-at (rx bol "-") s (defun my-filter-out-old-completed-todos (s backend info) "Filter out DONE items if they where completed over a week ago." (setq my-debug-items (add-to-list 'my-debug-items (list s backend info))) s) (org-export-define-derived-backend 'my-status-report 'ascii :options-alist '((:with-todo-keywords nil) (:num nil)) :filters-alist '((:filter-plain-list . my-filter-out-done-lines) (:filter-headline . my-filter-out-old-completed-todos))) ;; Snarf the weeks activities (save-excursion (goto-char (point-min)) (when (re-search-forward "* Tasks") (goto-char (match-beginning 0)) (org-export-as 'my-status-report t nil t ))) #+end_src When I poke around in my-debug-items to work out the correct furtling I need to do I inevitably lock up Emacs as the pretty printer struggles to dump the entire org AST in :parent. Is there anyway of suppressing the :parent and associated data so I can just concentrate on the data for the actual node I have? -- Alex Bennée
Re: [O] Hooking document specific src blocks into default actions
Alex Bennée writes: > Hi, > > I've been using these for a while but I recently wanted to add a > function at the head of the ctrl-c-ctrl-c processing: > > (defvar my-org-default-action nil > "Default action for this document to run on `org-ctrl-c-ctrl-c'. > \\ > This will run via `org-ctrl-c-ctrl-c-hook' and should return a > non-nil result if it processed something. As such it can override > default `org-mode' behaviour for \\[org-ctrl-c-ctrl-c]. If you > want something to run at the end then you need to use > `my-org-default-code-block'") > (make-variable-buffer-local 'my-org-default-action) > > (defun my-org--do-action (func-or-string) > "Evaluate a code block or call a function `FUNC-OR-STRING' from org-file." > (let ((current-point (point))) > (cond >((stringp func-or-string) > (save-excursion > (org-babel-goto-named-src-block func-or-string) > (org-babel-when-in-src-block >(org-babel-eval-wipe-error-buffer) >(org-babel-execute-src-block current-prefix-arg nil > '((:called-from . current-point)) > ((functionp func-or-string) > (funcall func-or-string)) > (t (error "What to do with: %s" func-or-string) OK the problem here was org-babel-when-in-src-block wraps the result. So now I have a simpler: (defun my-org--do-action (func-or-string) "Evaluate a code block or call a function `FUNC-OR-STRING' from org-file." (let ((action-result)) (cond ((stringp func-or-string) (save-excursion (org-babel-goto-named-src-block func-or-string) (when (memq (org-element-type (org-element-context)) '(inline-src-block src-block)) (org-babel-eval-wipe-error-buffer) (setq action-result (org-babel-execute-src-block t) ((functionp func-or-string) (setq action-result (funcall func-or-string))) (t (error "What to do with: %s" func-or-string))) (if action-result (message "%s: %s" func-or-string action-result) nil))) This works well, so on to the next problem. I have in my org file: # -*- my-org-default-action: "team-default-action" -*- with: #+name: team-default-action #+begin_src emacs-lisp (let ((called-point (car org-mark-ring)) (processed)) (save-excursion (message "Checking at: %s" called-point) (goto-char called-point) (when (org-at-heading-p) (let ((heading (nth 4 (org-heading-components))) (virt-rx (rx "[virt:" (group (one-or-more digit)) "]"))) (when (string-match virt-rx heading) (let ((ticket (match-string 1 heading))) (message "found: %s with %s" heading ticket) (org-sbe "update-ticket" (virt-ticket ticket)) (setq processed (format "Updated ticket: %s/%s" heading ticket))) (unless processed (message "No default action")) processed) #+end_src However as this block needs to call the various helper functions I'm using the org-sbe macro. However I can't work out how to evaluate "ticket" in a way to keep the macro happy. Obviously it is designed for use in tables so I'm possibly abusing it beyond what it can do. Any ideas? -- Alex Bennée
[O] Hooking document specific src blocks into default actions
Hi, I've been using these for a while but I recently wanted to add a function at the head of the ctrl-c-ctrl-c processing: (defvar my-org-default-action nil "Default action for this document to run on `org-ctrl-c-ctrl-c'. \\ This will run via `org-ctrl-c-ctrl-c-hook' and should return a non-nil result if it processed something. As such it can override default `org-mode' behaviour for \\[org-ctrl-c-ctrl-c]. If you want something to run at the end then you need to use `my-org-default-code-block'") (make-variable-buffer-local 'my-org-default-action) (defun my-org--do-action (func-or-string) "Evaluate a code block or call a function `FUNC-OR-STRING' from org-file." (let ((current-point (point))) (cond ((stringp func-or-string) (save-excursion (org-babel-goto-named-src-block func-or-string) (org-babel-when-in-src-block (org-babel-eval-wipe-error-buffer) (org-babel-execute-src-block current-prefix-arg nil '((:called-from . current-point)) ((functionp func-or-string) (funcall func-or-string)) (t (error "What to do with: %s" func-or-string) (defun my-org-run-default-action () "Execute default action for this org file." (interactive) (when my-org-default-action (my-org--do-action my-org-default-action))) (add-to-list 'org-ctrl-c-ctrl-c-hook 'my-org-run-default-action) However I've run into a small problem that when I execute the source block I end up with 't every time as we successfully executed the block even if it didn't end up doing anything at the time. Is there a better way to invoke source blocks from the current org-document than this? One where the eventual result can be returned into the calling lisp so org-ctrl-c-ctrl-c-hook can move on if we didn't do anything? -- Alex Bennée
Re: [O] Table (used a "spreadsheet") org-sbe issues when the value is a string
Alex Bennée writes: > Nicolas Goaziou writes: > >> Hello, >> >> Alex Bennée writes: >> >>> So calling scramble-string works as expected... >>> >>> #+tblname: reversed-strings >>> | abcde | #ERROR | >>> >>> | flibble | #ERROR | >>> | dibble | #ERROR | >>> | xyzzy | #ERROR | >>> | another | #ERROR | >>> >>> #+TBLFM: $2='(org-sbe scramble-string (str $$1)) >> >> I cannot reproduce it. I get: > > Hmm it turns out this interferes: > > ;; See > http://emacs.stackexchange.com/questions/499/finding-and-executing-org-babel-snippets-programatically > (defun my-babel-hashed-confirm (lang body) > > (setq org-confirm-babel-evaluate 'my-babel-hashed-confirm) > > Resetting to org-confirm-babel-evaluate to nil and it works. So more correctly when org-confirm-babel-evaluate is set it breaks due to info not containing a character position for the TBLFM code. I fixed this by patching org-babel-check-confirm-evaluate: modified lisp/ob-core.el @@ -242,7 +242,8 @@ should be asked whether to allow evaluation." (and export (equal eval "query-export")) (if (functionp org-confirm-babel-evaluate) (save-excursion - (goto-char (nth 5 info)) + (when (nth 5 info) + (goto-char (nth 5 info))) (funcall org-confirm-babel-evaluate ;; language, code block body (nth 0 info) (nth 1 info))) I'm not sure the goto-char is legitimate anyway as the documentation for org-confirm-babel-evaluate says nothing about point being set while it executes. -- Alex Bennée
Re: [O] Table (used a "spreadsheet") org-sbe issues when the value is a string
Nicolas Goaziou writes: > Hello, > > Alex Bennée writes: > >> So calling scramble-string works as expected... >> >> #+tblname: reversed-strings >> | abcde | #ERROR | >> >> | flibble | #ERROR | >> | dibble | #ERROR | >> | xyzzy | #ERROR | >> | another | #ERROR | >> >> #+TBLFM: $2='(org-sbe scramble-string (str $$1)) > > I cannot reproduce it. I get: Hmm it turns out this interferes: ;; See http://emacs.stackexchange.com/questions/499/finding-and-executing-org-babel-snippets-programatically (defun my-babel-hashed-confirm (lang body) "Check against known hashes before prompting for confirmation. See `org-confirm-babel-evaluate'." (let ((check (list lang (md5 body ;; If not hashed, prompt (if (not (member check my-org-babel-hashes)) ;; Ask if you want to hash (if (yes-or-no-p "Store hash for block? ") ;; Hash is added, proceed with evaluation (progn (add-to-list 'my-org-babel-hashes check) 'nil) ;; Return 't to prompt for evaluation 't) (message "Valid hash auto-confirmed") 'nil))) (setq org-confirm-babel-evaluate 'my-babel-hashed-confirm) Resetting to org-confirm-babel-evaluate to nil and it works. > > #+name: reversed-strings > | abcde | edcba | > | flibble | elbbilf | > | dibble | elbbid | > | xyzzy | yzzyx | > | another | rehtona | > #+TBLFM: $2='(org-sbe scramble-string (str $$1)) > >> Even calling org-sbe directly from a source block: >> >> #+name: call-scramble-string-via-sbe >> #+begin_src emacs-lisp :var val="thing" >> >> (org-sbe scramble-string (str val)) >> #+end_src > > AFAIK, `org-sbe' is limited to tables. I was trying to replicate the way TBLFM compiles the macro. > > Regards, -- Alex Bennée
Re: [O] Table (used a "spreadsheet") org-sbe issues when the value is a string
Nicolas Goaziou writes: > Hello, > > Frederick Giasson writes: > >> Now, if I put a string in the format column, I al getting the following: >> >> >> >> #+NAME: average-dataset-size >> #+BEGIN_SRC clojure :var f="turtle" :exports none :results value >> (identity f) #+END_SRC >> >> #+RESULTS: average-dataset-size >> : turtle >> >> >> | Format | Sizes distribution in MB | Average size in MB | >> |+--+| >> | turtle | | #ERROR | >> #+TBLFM: $3='(org-sbe "average-dataset-size" (f $1)) >> >> > > According to `org-sbe' docstring, it should be > > #+TBLFM: $3='(org-sbe "average-dataset-size" (f $$1)) > > Documentation could be drastically improved in that area, the manual is > not even talking about `org-sbe'. Even this doesn't seem to work. In my case: #+name: scramble-string #+begin_src emacs-lisp :var str="abcde" (apply #'string (reverse (string-to-list str))) #+end_src #+RESULTS: scramble-string : edcba So far so good #+call: scramble-string(str="whatever-foo") #+RESULTS: : oof-revetahw So calling scramble-string works as expected... #+tblname: reversed-strings | abcde | #ERROR | | flibble | #ERROR | | dibble | #ERROR | | xyzzy | #ERROR | | another | #ERROR | #+TBLFM: $2='(org-sbe scramble-string (str $$1)) Hmm no dice... the debugger lists: Substitution history of formula Orig: '(org-sbe scramble-string (str $$1)) $xyz-> '(org-sbe scramble-string (str $$1)) @r$c-> '(org-sbe scramble-string (str $$1)) $1->'(org-sbe scramble-string (str $"abcde")) Result: #ERROR Format: NONE Final: #ERROR Even calling org-sbe directly from a source block: #+name: call-scramble-string-via-sbe #+begin_src emacs-lisp :var val="thing" (org-sbe scramble-string (str val)) #+end_src So is this just broken untested functionality or are there any working examples from which we could reverse engineer the proper docstring? -- Alex Bennée
Re: [O] ob-async
Ken Mankoff writes: > An RSS feed I follow mentioned ob-async here: > https://github.com/astahlman/ob-async > > I haven't seen it mentioned on the list yet. Perhaps others would be > interested in asynchronous Babel processing. I've seen the feature > requested often on this list. This is not the first attempt to my knowledge. I know of: - my hacky attempt https://github.com/stsquad/async-org-babel - John Kitchen's python specific version http://kitchingroup.cheme.cmu.edu/blog/2015/11/20/Asynchronously-running-python-blocks-in-org-mode/ - this matlab version http://emacs.stackexchange.com/questions/21301/async-execution-in-org-babel So I think there have been enough proof of concepts of using async.el and inserting results at a later date. I think what would be really useful is some feedback from the org-mode maintainers about the various approaches and if something generic could be included with org-mode itself. Any thoughts? -- Alex Bennée
[O] Capturing the results of shell execution
I'm using org-babel snippets to automate some of my workflow. However I'm not interested in dumping all of the compile output, I'd rather get a simple value at the end to see if all was OK: #+name: build-test #+begin_src sh :results value set -e ./configure --cross-prefix=aarch64-linux-gnu- --arch=arm64 make clean make -j9 #+end_src However there isn't a way to tell the difference between a failing sequence and a passing one apart from *Org-Babel Error Output* being popped up. It seems org-babel-eval just slurps up the return code and blindly returns (buffer-string) regardless of the desires of the :results keyword. Is this an intentional limitation of babels sh evaluation? Redirecting all the compile output in the snippet seems a little clumsy a solution: #+name: build-test #+begin_src sh :results output set -e ./configure --cross-prefix=aarch64-linux-gnu- --arch=arm64 make clean > /dev/null make -j9 > /dev/null echo "Build complete: `date`" #+end_src Ideally I'd like #+RESULTS to have a nice 0/1 which can be used to gate other parts of the process. Am I missing something? -- Alex Bennée
[O] Switching buffers from babel snippets
Hi, I've trying to further automate my maintainer tasks by moving things into babel snippets. I have one to find a cover letter and edit the file: #+name: edit-cover-letter #+begin_src emacs-lisp :var cover=create-qemu-pull[0] (find-file (expand-file-name (concat default-directory (car cover (mail-mode) #+end_src However when I run the code although the file is loaded and in the right mode I never see the buffer come up and have to switch to it manually. I expect this is because the code is running under some sort of safe-excursion. Is there anyway to pass a final buffer back to org-mode after the code is run and switch to it? -- Alex Bennée
[O] bug#23917: bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)
Eli Zaretskii writes: >> From: Alex Bennée >> Cc: monn...@iro.umontreal.ca, 23...@debbugs.gnu.org, rpl...@gmail.com, >> jwieg...@gmail.com, nljlistb...@gmail.com, m...@lunaryorn.com >> Date: Tue, 19 Jul 2016 18:45:44 +0100 >> >> ;; Save and restore the match data, as recommended in (elisp)Change Hooks >> (save-match-data >> (when flycheck-mode >> ;; The buffer was changed, thus clear the idle timer >> (flycheck-clear-idle-change-timer) >> (if (string-match-p (rx "\n") (buffer-substring beg end)) >> (flycheck-buffer-automatically 'new-line 'force-deferred) >> (setq flycheck-idle-change-timer >> (run-at-time flycheck-idle-change-delay nil >>#'flycheck-handle-idle-change)) >> >> However it doesn't look as though it tweaks the buffer until idle timer >> has run. Weird > > Tweaking the buffer is not what causes the problem. It's the call to > save-match-data itself. It doesn't matter at all what the code inside > save-match-data does. Ahh I misunderstood the description of the problem. I thought it was a changing of the buffer underneath that meant the match data wasn't updated and hence got out of sync. So is the match data already out of sync by the time the save-match-data call is made? -- Alex Bennée
[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)
Eli Zaretskii writes: >> From: Alex Bennée >> Cc: Stefan Monnier , 23...@debbugs.gnu.org, >> rpl...@gmail.com, jwieg...@gmail.com, nljlistb...@gmail.com >> Date: Tue, 19 Jul 2016 18:05:37 +0100 >> >> > Do we care that using save-match-data in every call to replace-match >> > might mean a performance hit? If it will, then this will again punish >> > most of the users for the benefit of those few who (1) have >> > buffer-modification hooks, and (2) those hooks call save-match-data. >> >> I care unless there is an easy way to identify which buffer modification >> hooks are responsible so I can take steps as a user to mitigate the >> problems. > > Any hook in before-change-functions or after-change-functions that > calls save-match-data. > > If we care about the performance hit, we need to come up with a > different solution for this problem (or measure the performance hit > and convince ourselves it is not a big deal). Thanks for the hint. So in my case it was flycheck-handle-change which was triggering the problem: (defun flycheck-handle-change (beg end _len) "Handle a buffer change between BEG and END. BEG and END mark the beginning and end of the change text. _LEN is ignored. Start a syntax check if a new line has been inserted into the buffer." ;; Save and restore the match data, as recommended in (elisp)Change Hooks (save-match-data (when flycheck-mode ;; The buffer was changed, thus clear the idle timer (flycheck-clear-idle-change-timer) (if (string-match-p (rx "\n") (buffer-substring beg end)) (flycheck-buffer-automatically 'new-line 'force-deferred) (setq flycheck-idle-change-timer (run-at-time flycheck-idle-change-delay nil #'flycheck-handle-idle-change)) However it doesn't look as though it tweaks the buffer until idle timer has run. Weird -- Alex Bennée
[O] bug#23917: bug#23917: Please consider making Bug #23917 a blocker for 25.1 (was Re: org-capture: Capture template ‘g’: Match data clobbered by buffer modification hooks)
Eli Zaretskii writes: >> From: Stefan Monnier >> Cc: rpl...@gmail.com, 23...@debbugs.gnu.org, alex.ben...@linaro.org, >> jwieg...@gmail.com, nljlistb...@gmail.com >> Date: Tue, 19 Jul 2016 12:03:51 -0400 >> >> I guess the next best thing is: >> - copy search_regs.start and search_regs.end before calling replace_range. >> - use that copy when adjusting the match data. >> Or equivalently, use save-match-data. IOW go back to your original patch. >> Duh! > > Do we care that using save-match-data in every call to replace-match > might mean a performance hit? If it will, then this will again punish > most of the users for the benefit of those few who (1) have > buffer-modification hooks, and (2) those hooks call save-match-data. I care unless there is an easy way to identify which buffer modification hooks are responsible so I can take steps as a user to mitigate the problems. -- Alex Bennée
[O] Best approaches for implementing a developer workflow using ORG?
Comment (email)" checkitem (file+headline "review.org" "Review Comments") " - [ ] %a"))) #+end_src But that seemed to cause problems when capturing multiple checkbox links in a row. Maybe there is some way to stuff some meta-data in the link? However ideally I'd like to solve the problem of programitically following org-links as I'd like to automate the bringing up of review comments when I doing re-basing. It is of course possible that I'm abusing org-mode a bit too much using it in this way and I should use something more database like to store this stuff. However I would appreciate any suggestions of ways to tackle this problem. Regards, -- Alex Bennée
Re: [O] Change in ox export for #+DATE keywords
Alex Bennée writes: > Nicolas Goaziou writes: > >> Alex Bennée writes: >> >>> Nicolas Goaziou writes: >>>> FWIW, I export it without an error. Do you use a custom export >>>> back-end? >>> >>> I'm using ox-reveal (for Reveal.js). I'm finding it hard to trigger an >>> actual backtrace so maybe the problem is there. >> >> I've had a cursory look at ox-reveal.el[fn:1]. There is a strange thing, >> indeed. In `org-reveal-template', line 888, (plist-get info :author) >> should be wrapped within (org-export-data ...). >> >> However, it is not related to your error. Therefore, I suspect an >> installation problem on your side. > > I've tried re-building all my elpa packages as well as doing a plaing > HTML export and I can now get a backtrace: > OK ignore that. If I do a -q -l mininit.el I get a more useful backtrace that reveals problems with ox-reveal.el which I can address. -- Alex Bennée
Re: [O] Change in ox export for #+DATE keywords
Nicolas Goaziou writes:
> Alex Bennée writes:
>
>> Nicolas Goaziou writes:
>>
>>> Hello,
>>>
>>> Alex Bennée writes:
>>>
>>>> I've been using org-mode as a source for my presentations but exporting
>>>> broke today following an ELPA update. It seems the line:
>>>>
>>>> #+DATE: KVM Forum 2015
>>>>
>>>> Is no longer acceptable.
>>>
>>> FWIW, I export it without an error. Do you use a custom export
>>> back-end?
>>
>> I'm using ox-reveal (for Reveal.js). I'm finding it hard to trigger an
>> actual backtrace so maybe the problem is there.
>
> I've had a cursory look at ox-reveal.el[fn:1]. There is a strange thing,
> indeed. In `org-reveal-template', line 888, (plist-get info :author)
> should be wrapped within (org-export-data ...).
>
> However, it is not related to your error. Therefore, I suspect an
> installation problem on your side.
I've tried re-building all my elpa packages as well as doing a plaing
HTML export and I can now get a backtrace:
Debugger entered--Lisp error: (wrong-type-argument listp #("Towards
multi-threaded TCG" 0 26 (:parent (#1
org-element-set-contents(#("Towards multi-threaded TCG" 0 26 (:parent (#0
apply(org-element-set-contents #("Towards multi-threaded TCG" 0 26 (:parent
(#0))) nil)
#[(s) "\306\307\310#\311\312
\211:\204 \313\202\" @9\203! AA\202\" )\"\210\314\315\n
\211:\2043\313\202@ @9\203? AA\202@ )#\210
\316\211\n ;\203V\317\320\f #\202\\\321 A@\f\"* \211;\203n\322 \313\f$\202z A\323 A@\f#\240\210 +\210\nA
A@\240\210\n@\240*\207" [s new old element property value
replace-regexp-in-string "\n" " " mapc #[(blob) "\305
\211;\203 \306\f\307 \n$\202 \fA\310\fA@ \n#\240\210\f+\207" [blob old value
property element :parent org-add-props nil plist-put] 6] nil apply
org-element-set-contents :parent get-text-property 0 plist-get org-add-props
plist-put] 6](#("Towards multi-threaded TCG" 0 26 (:parent (#0
#[(--data) "\211:\204 ;\205 \306\202 @9\205
@)?\206\337 \203,\307 \310\">\206\337\n\2047\311\f\"\202\337\n\312=\203\\\311\f\211:\204J\313\202W
@9\203V AA\202W
)\"\202\337\n>\203\202!\211\203\201\203z\314\315\"\210\202\201B)\316=\203\312;\204\312\n\236A\313\211\203\311@\f
;\203\266\317\320 #\202\275\307
A@ \"*!\210A\211\204\234* \203\202\316=\203\202\n >\203\202 \313
\211\203\201@\211 @ A ;\203\317\320 #\202 \307
A@ \"*!\"!\203w\"#\235\203_\"$\235\203P\321!!\313%\211\203L@%\f%A!\210\f%@!\210A\211\2042*\202w\f!A!\210\f!@!\210\202w\"$\235\203r\311\f\321!!\"\210\202w\f!!\210*A\211\204\350*\n&>\206\337\211:\204\224\313\202\241
@9\203\240 AA\202\241
)?\206\337\322=\203\265\n'>?\206\337\323=\203\303\n(>\206\337\311\f\211:\204\320\313\202\335
@9\203\334 AA\202\335 )\")\207" [--data element --type info
--walk-tree types plain-text plist-get :ignore-list mapc org-data nil throw
--map-first-match objects get-text-property 0 reverse greater-elements elements
fun result first-match --acc --category org-element-secondary-value-alist p
--dolist-tail-- property with-affiliated org-element-all-elements
org-element--parsed-properties-alist kwd-pair value kwd
org-element-dual-keywords org-element-multiple-keywords line no-recursion
org-element-greater-elements org-element-all-objects] 6](#("Towards
multi-threaded TCG" 0 26 (:parent (#0
mapc(#[(--data) "\211:\204 ;\205 \306\202 @9\205
@)?\206\337 \203,\307 \310\">\206\337\n\2047\311\f\"\202\337\n\312=\203\\\311\f\211:\204J\313\202W
@9\203V AA\202W
)\"\202\337\n>\203\202!\211\203\201\203z\314\315\"\210\202\201B)\316=\203\312;\204\312\n\236A\313\211\203\311@\f
;\203\266\317\320 #\202\275\307
A@ \"*!\210A\211\204\234* \203\202\316=\203\202\n >\203\202 \313
\211\203\201@\211 @ A ;\203\317\320 #\202 \307
A@ \"*!\"!\203w\"#\235\203_\"$\235\203P\321!!\313%\211\203L@%\f%A!\210\f%@!\210A\211\2042*\202w\f!A!\210\f!@!\210\202w\"$\235\203r\311\f\321!!\"\210\202w\f!!\210*A\211\204\350*\n&>\206\337\211:\204\224\313\202\241
@9\203\240 AA\202\241
)?\206\337\322=\203\265\n'>?\206\337\323=\203\303\n(>\206\337\311\f\211:\204\320\313\202\335
@9\203\334 AA\202\335 )\")\207" [--data element --type info
--walk-tree types plain-text plist-get :ignore-list mapc org-data nil throw
--map-first-match objects get-text-property 0 reverse greater-elements elements
fun result first-mat
Re: [O] Change in ox export for #+DATE keywords
Nicolas Goaziou writes: > Hello, > > Alex Bennée writes: > >> I've been using org-mode as a source for my presentations but exporting >> broke today following an ELPA update. It seems the line: >> >> #+DATE: KVM Forum 2015 >> >> Is no longer acceptable. > > FWIW, I export it without an error. Do you use a custom export > back-end? I'm using ox-reveal (for Reveal.js). I'm finding it hard to trigger an actual backtrace so maybe the problem is there. > > > Regards, -- Alex Bennée
Re: [O] Change in ox export for #+DATE keywords
Peter Salazar writes:
> As I mentioned, I'm getting that same error, not just with #+DATE but also
> with #+TITLE, #+AUTHOR, etc. Any one of these is sufficient to break export
> for me.
Yeah further poking has shown they have all broken. I can't quite follow
the logic of the patch as to what the new parse is expecting.
>
> On Fri, Aug 7, 2015 at 3:59 PM, Alex Bennée wrote:
>
>> Hi,
>>
>> I've been using org-mode as a source for my presentations but exporting
>> broke today following an ELPA update. It seems the line:
>>
>> #+DATE: KVM Forum 2015
>>
>> Is no longer acceptable. I think this changed as of:
>>
>> ae9db17482a183e5613428c3abf1c691f86b4ac0
>>
>> I'm not quite sure what the new "parse" is expecting. If I change it to
>> a datestamp I see breakage on other lines like the title:
>>
>> apply: Wrong type argument: listp, #("My presentation title" 0 26 (:parent
>> (#0)))
>>
>> So what form am I meant to be using for these options and why the change?
>>
>> --
>> Alex Bennée
>>
>>
--
Alex Bennée
[O] Change in ox export for #+DATE keywords
Hi,
I've been using org-mode as a source for my presentations but exporting
broke today following an ELPA update. It seems the line:
#+DATE: KVM Forum 2015
Is no longer acceptable. I think this changed as of:
ae9db17482a183e5613428c3abf1c691f86b4ac0
I'm not quite sure what the new "parse" is expecting. If I change it to
a datestamp I see breakage on other lines like the title:
apply: Wrong type argument: listp, #("My presentation title" 0 26 (:parent
(#0)))
So what form am I meant to be using for these options and why the change?
--
Alex Bennée
Re: [O] Correct way to insert results
Alex Bennée writes: > Hi, > > I'm working on adding async call functionality to org-babel blocks so I > don't need to block my main Emacs for long running calculations. However > I'm having problems with the insertion of the results once handled. Ping? Is this something I should just write a custom routine for to replace a token generated at the initial call? > My > code looks like this: > > (defmacro async-org-call (async-form) > "Expands `ASYNC-FORM' as an asynchronus org-bable function. > If executed inside an org file will insert the results into the src > blocks results. Otherwise the result will be echoed to the Message > buffer." > > (let ((result-buffer (buffer-name)) > (result-org-name (nth 4 (org-babel-get-src-block-info > > `(async-start > > ;; The result of the async-sexp is returned to the handler > ;; as result. > (lambda () > ,(async-inject-variables "async-form") > (eval async-form)) > > ;; This code runs in the current emacs process. > (lambda (result) > (let ((buf ,result-buffer) > (org ,result-org-name)) > > ;; Send the results somewhere > (if (and buf org) > (save-excursion > (with-current-buffer buf > (org-babel-goto-named-result org) > (org-babel-insert-result (format "%s" result > (message (pp (format "async-result: %s" result) > > However the insert result seems to keep skipping the named result I'm > aiming for (I was calling basic-async-test, the results end up after > async-with-delay in a fresh RESULTS: drawer): > > ** Basic async > > #+name: basic-async-test > #+begin_src emacs-lisp > (async-org-call (format "this is in inferior")) > #+end_src > > #+RESULTS: basic-async-test > : # > > #+name: async-with-delay > #+begin_src emacs-lisp > (async-org-call ((sleep-for 3) (format "woken up"))) > #+end_src > > #+RESULTS: > =this is in inferior > =: this is in inferior > > #+RESULTS: async-with-delay > : # > > Any idea how I can do this better? -- Alex Bennée
[O] Correct way to insert results
Hi, I'm working on adding async call functionality to org-babel blocks so I don't need to block my main Emacs for long running calculations. However I'm having problems with the insertion of the results once handled. My code looks like this: (defmacro async-org-call (async-form) "Expands `ASYNC-FORM' as an asynchronus org-bable function. If executed inside an org file will insert the results into the src blocks results. Otherwise the result will be echoed to the Message buffer." (let ((result-buffer (buffer-name)) (result-org-name (nth 4 (org-babel-get-src-block-info `(async-start ;; The result of the async-sexp is returned to the handler ;; as result. (lambda () ,(async-inject-variables "async-form") (eval async-form)) ;; This code runs in the current emacs process. (lambda (result) (let ((buf ,result-buffer) (org ,result-org-name)) ;; Send the results somewhere (if (and buf org) (save-excursion (with-current-buffer buf (org-babel-goto-named-result org) (org-babel-insert-result (format "%s" result (message (pp (format "async-result: %s" result) However the insert result seems to keep skipping the named result I'm aiming for (I was calling basic-async-test, the results end up after async-with-delay in a fresh RESULTS: drawer): ** Basic async #+name: basic-async-test #+begin_src emacs-lisp (async-org-call (format "this is in inferior")) #+end_src #+RESULTS: basic-async-test : # #+name: async-with-delay #+begin_src emacs-lisp (async-org-call ((sleep-for 3) (format "woken up"))) #+end_src #+RESULTS: =this is in inferior =: this is in inferior #+RESULTS: async-with-delay : # Any idea how I can do this better? -- Alex Bennée
