Re: [HELP] Request for patches to improve Org test coverage
Ihor Radchenko writes: > Dear Fellow Orgers, > > Despite being not directly visible to users, Org mode testing suite is > critical to maintain overall codebase stability. It helps to avoid > unintentional breakages as we keep adding new features to Org. [] > - Generally, more and better tests would be welcome. Hello, Thanks for calling for tests improvement with such rationale. I submitted my small test patch for a bug in babel/shell early this year (unfortunately I was not able to fix the bug). I still think that the test is valuable for inclusion. If not, please give feedback. See the original mail at: <87h7jhus7k.fsf@spx.local.examples> Best, Daniele
babel output seems to drop anything before % (in session)
Hello,
Try to execute a few times the following and see the output corrupted in
the line:
#+BEGIN_EXAMPLE
1 packets transmitted, 1 received, 0% packet loss, time 0ms
#+END_EXAMPLE
#+PROPERTY: header-args:shell
#+PROPERTY: header-args:shell+ :results output verbatim :wrap src text :session
test
#+NAME: ping
#+BEGIN_SRC shell
ping -c 1 127.0.0.1
#+END_SRC
I tried to write a test (now with the :expected-result :failed), that
hit the problem both in main and master (applies fine to both).
I was not able to fix it, but hopefully the tests are still useful for
somebody more knowledgeable!
Thanks for you suggestion/fix!
Best,
Daniele
>From 897ae50cf055d459d741c90f8de94dd56a8eb3d9 Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli
Date: Wed, 5 May 2021 17:00:28 +0200
Subject: [PATCH 1/1] Add disabled test for % in babel shell output
---
testing/lisp/test-ob-shell.el | 29 +
1 file changed, 29 insertions(+)
diff --git a/testing/lisp/test-ob-shell.el b/testing/lisp/test-ob-shell.el
index 0aadb355d..a42cc3d77 100644
--- a/testing/lisp/test-ob-shell.el
+++ b/testing/lisp/test-ob-shell.el
@@ -106,6 +106,35 @@ ob-comint.el, which was not previously tested."
"#+BEGIN_SRC sh :results output :var l='(1 2)\necho ${l}\n#+END_SRC"
(org-trim (org-babel-execute-src-block))
+(ert-deftest ob-shell/percent-simple ()
+ "Test percent in output."
+ (should
+ (equal "one 0% two\ntree 0% four"
+ (org-test-with-temp-text
+ "#+BEGIN_SRC bash :results output verbatim\necho one 0% two\necho tree 0% four\n#+END_SRC"
+ (org-trim (org-babel-execute-src-block)
+ (should
+ (equal "five 0% two\ntree 0% four"
+ (org-test-with-temp-text
+ "#+BEGIN_SRC bash :results output verbatim\necho five 0% two\necho tree 0% four\n#+END_SRC"
+ (org-trim (org-babel-execute-src-block))
+
+(ert-deftest ob-shell/percent-session ()
+ "Test percent in output for session.
+
+At the second iteration the string before % is dropped."
+ :expected-result :failed
+ (should
+ (equal "one 0% two\ntree 0% four"
+ (org-test-with-temp-text
+ "#+BEGIN_SRC bash :results output verbatim :session sess\necho one 0% two\necho tree 0% four\n#+END_SRC"
+ (org-trim (org-babel-execute-src-block)
+ (should
+ (equal "five 0% six\nseven 0% eight"
+ (org-test-with-temp-text
+ "#+BEGIN_SRC bash :results output verbatim :session sess\necho five 0% six\necho seven 0% eight\n#+END_SRC"
+ (org-trim (org-babel-execute-src-block))
+
(provide 'test-ob-shell)
;;; test-ob-shell.el ends here
--
2.29.2
Re: [O] Insert git hash into exported document
David Talmage writes:
> I'd like to insert the git hash of HEAD in the org-mode documents that I
> export. Is there an easy way? I'm exporting to LaTeX.
[]
Hello,
maybe you can start with a simple:
#+NAME: hash-from-lisp
#+BEGIN_SRC emacs-lisp
(shell-command-to-string "git rev-parse HEAD" )
#+END_SRC
#+RESULTS: hash-from-lisp
: 099b6ceee7264832b8e13f1156974b8017e6e4bb
You can hide the result using proper headers or the noexport tag and
then print the result in a verbose way:
The latest commit hash is src_emacs-lisp[:var i=hash-from-lisp]{(format "%s" i)}
or if you enable the shell in babel you can start with:
#+NAME: hash-from-shell
#+BEGIN_SRC shell
git rev-parse HEAD
#+END_SRC
For latex only, I use the following snippets. This works with gitinfo2
(in debian you need the packages texlive-latex-extra and
texlive-latex-extra-doc). Sorry for the long lines...
Please note that this will also highlight the dirty status of the repo,
since adding the latest hash for a modified version make little sense.
Best,
Daniele
#+LATEX_HEADER: \usepackage[,missing={Unknown},dirty={-- Uncommited
Changes!!!},notags={Unknown},mark]{gitinfo2}
#+LATEX: \renewcommand{\gitMarkPref}{Historical Info}
# NOTE: \gitTags does not work well: it adds a traling ")"
# NOTE: \gitReln takes the latest release, even there are more commits
#+LATEX:
\renewcommand{\gitMark}{Version:\space{}\gitTags{}\space{}--\space{}Id::\space{}\gitAbbrevHash\space{}--\space{}Date:\space{}\gitAuthorIsoDate\space{}\gitDirty}
#+BEGIN_SRC emacs-lisp
(defun update-gitinfo (backend)
"Update .git/gitHeadInfo.gin"
(message "Command: %s" (shell-command-to-string "cd `git rev-parse
--show-toplevel` && /bin/bash
/usr/share/doc/texlive-doc/latex/gitinfo2/post-xxx-sample.txt"))
(message "Updated gitinfo"))
(add-hook 'org-export-before-processing-hook #'update-gitinfo)
#+END_SRC
Re: [O] Open Peer-Review Reproducible Publication with Org and GRASS
On Fri, Jun 03 2016, Ken Mankoff wrote: > Hi Org and GRASS lists, > > I just wanted to let these two lists know that I've just posted a > paper written in Org and using GRASS (text-mode) and Python for the > analysis. My goal was to create not just an open access publication, > but a fully reproducible publication. This is an early announcement, > and the paper may not pass peer review. Hello Ken, Thanks for sharing, I had only a brief look. In the meantime some early thoughts while it downloads the data. [] > To make it easier to reproduce... including my emacs.org seems > overkill. Including a Virtual Machine that contains everything, > including my ~/.emacs.d/ and all the software and data seems like the > right thing to do, but journals don't want to host a 20 GB VM with the > publication. Well, you need only the recipe to build the VM. Fortunately there are a lot of tools that help to do this. Unfortunately there are too many, and not all of them focus on the reproducible side... In the meantime I saw few main problems in your current document: - No "One build step" - Hardcoded path, for example root = "/Users/mankoff/Documents/Papers/B/Brinkerhoff/" - I did not found the Grass installation part, I guess I will have an error later... - Missing latex toolchain installation Are you interested in fixing those issues? If yes please share your progress or ideas. Best, Daniele
Re: [O] Open Peer-Review Reproducible Publication with Org and GRASS
On Fri, Jun 03 2016, Brett Viren wrote: > Thanks for your example. > > A few ideas: > > - When you begin developing your paper, or sometime before submission, > make a break from your personal ~/.emacs.d/ environment and begin > processing the .org in an explicitly configured Emacs session. Submit > the needed, minimal, paper-specific Emacs setup as part of the > supplementary material. > > - Bundle the document building into a shell script which calls Emacs so > that you can assure that personal ~/.emacs.d/ is excluded and only the > paper-specific Emacs setup is used. It also helps users to rebuild > the paper, especially if they may not yet be Emacs aficionados. Hello, nice, but I suggest to start from scratch in a Virtual Machine. I am currently trying to develop a generic extensible template for this. Right now I did only custom tailored installation. When I have something interesting I will share it. In the meantime I will follow thread related to this topic closely! > - Instead of multi-GB VM image, provide a few kB Dockerfile which can be > used to build a Linux container with base OS and all required > applications needed to run the Babel code blocks. > > - The Dockerfile could go so far as to create a user account, get the > supplementary material from a repository or the publisher's web page, > unpack and run the shell script which calls Emacs to build the > document. If you go this far then in principle just this Dockerfile > is enough to reproduce the paper - but this will rely on some binaries > to remain available (Docker base OS images and OS packages). > > The reliance on long-term availability of the Docker base OS image and > binary packages is problematic for long term automated reproducibility. > However, even after those bits disappear from the 'net the Dockerfile > serves as a concise and explicit recipe for future humans to follow. I think that using debian only packages and the debian archive you will be able to reproduce the environment with few effort in the future, but I did not ever tried hard. I will suggest to use are Vagrant rather than Docker (because it is simpler to star, expressive enough, supports free software only provider (like libvirt)) and some shell scripts or ansible playbooks. I do not know the licence of the data, but I suggest to make at least one private mirror and use a variable to switch between the two. You may also want to verify sha256sum and/or gpg signatures on the data and on the code (that should be hosted using a source code management system). Best, Daniele
Re: [O] Division of Org documentation: Org manual and Worg
On Wed, May 18 2016, Rasmus wrote: > Hi Daniele, > >> So... here is the patch for worg about python and utf-8! I skipped >> the part related to the tables, since I do not have a clean >> workaround. > > Thanks for contributing to Worg! > > For Worg you just need to have your ssh key added. Then you can push > changes yourself. > > http://orgmode.org/worg/worg-about.html > > You can email your public ssh key to e.g. Bastien (bzg at gnu dot org). Hello Rasmus, Done, just pushed the change succesfully! I will look forward to integrate more docs about org-mode and python. Of course feedback are welcome! Best, Daniele
Re: [O] Division of Org documentation: Org manual and Worg
On Wed, May 18 2016, Daniele Pizzolli wrote: > On Wed, May 18 2016, Rasmus wrote: > >> Daniele Pizzolli writes: >> >>> It would be nice to add them to the documentation, but I have not yet >>> figured out what is the appropriate way to send the patch! >> >> /That/ information happens to be on Worg :) >> >>http://orgmode.org/worg/org-contribute.html > > Thanks Rasmus, > > So... here is the patch for worg about python and utf-8! I skipped > the part related to the tables, since I do not have a clean > workaround. Oops, I correct a couple of typos with this one. Sorry for the noise. Daniele >From e885c2d7654dcf78cf37e5fd5b1e104545ecbd2f Mon Sep 17 00:00:00 2001 From: Daniele Pizzolli Date: Wed, 18 May 2016 11:55:00 +0200 Subject: [PATCH 1/1] Add caveats about uft-8 strings --- org-contrib/babel/languages/ob-doc-python.org | 52 ++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/org-contrib/babel/languages/ob-doc-python.org b/org-contrib/babel/languages/ob-doc-python.org index 968a8bc..8acfbff 100644 --- a/org-contrib/babel/languages/ob-doc-python.org +++ b/org-contrib/babel/languages/ob-doc-python.org @@ -25,7 +25,7 @@ #+end_html -* Template Checklist [10/12] :noexport: +* Template Checklist [11/14] :noexport: - [X] Revise #+TITLE: - [X] Indicate #+AUTHOR: - [X] Add #+EMAIL: @@ -42,6 +42,8 @@ - [ ] Describe [[Result%20Types][Result Types]] - [ ] Describe [[Other]] differences from supported languages - [X] Provide brief [[Examples%20of%20Use][Examples of Use]] + - [X] Add caveats about utf-8 in strings + - [ ] Add caveats about utf-8 in tables * Introduction Python is a high-level, readable, interpreted language which can be used for many common computing tasks. It runs on most modern @@ -242,3 +244,51 @@ return 'images/python-matplot-fig.png' # return filename to org-mode #+end_example [[file:images/python-matplot-fig.png]] + +* Caveats + +You need some care in order to pass utf-8 strings to python. + +** passing utf-8 strings to python + +#+begin_example +#+NAME: unicode_str +,#+BEGIN_EXAMPLE +“this string is not ascii!” +,#+END_EXAMPLE +#+end_example + +#+begin_example +#+NAME: error-in-passing-var +#+BEGIN_SRC python :var data=unicode_str +return data +#+END_SRC +#+end_example + +#+begin_example +#+RESULTS: error-in-passing-var +#+end_example + +Will produce no output and prints the following message in the buffer +=*Org-Babel Error Output*=: + +#+BEGIN_EXAMPLE + File "", line 3 +SyntaxError: Non-ASCII character '\xe2' in file on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details +#+END_EXAMPLE + +** passing utf-8 strings to python with workaround + +A workaround is to use =:preamble= with the value =# -*- coding:utf-8 -*-= + +#+begin_example +#+NAME: ok-in-passing-var +#+BEGIN_SRC python :preamble "# -*- coding: utf-8 -*-" :var data=unicode_str +return data +#+END_SRC +#+end_example + +#+begin_example +#+RESULTS: ok-in-passing-var +: “this string is not ascii!” +#+end_example -- 2.1.4
Re: [O] Division of Org documentation: Org manual and Worg
On Wed, May 18 2016, Rasmus wrote: > Daniele Pizzolli writes: > >> It would be nice to add them to the documentation, but I have not yet >> figured out what is the appropriate way to send the patch! > > /That/ information happens to be on Worg :) > >http://orgmode.org/worg/org-contribute.html Thanks Rasmus, So... here is the patch for worg about python and utf-8! I skipped the part related to the tables, since I do not have a clean workaround. Best, Daniele >From 91941d90d26e1715447fecc255d7976c0895e75d Mon Sep 17 00:00:00 2001 From: Daniele Pizzolli Date: Wed, 18 May 2016 11:55:00 +0200 Subject: [PATCH 1/1] Add caveats about uft-8 strings --- org-contrib/babel/languages/ob-doc-python.org | 52 ++- 1 file changed, 51 insertions(+), 1 deletion(-) diff --git a/org-contrib/babel/languages/ob-doc-python.org b/org-contrib/babel/languages/ob-doc-python.org index 968a8bc..e4619ed 100644 --- a/org-contrib/babel/languages/ob-doc-python.org +++ b/org-contrib/babel/languages/ob-doc-python.org @@ -25,7 +25,7 @@ #+end_html -* Template Checklist [10/12] :noexport: +* Template Checklist [11/14] :noexport: - [X] Revise #+TITLE: - [X] Indicate #+AUTHOR: - [X] Add #+EMAIL: @@ -42,6 +42,8 @@ - [ ] Describe [[Result%20Types][Result Types]] - [ ] Describe [[Other]] differences from supported languages - [X] Provide brief [[Examples%20of%20Use][Examples of Use]] + - [X] Add caveats about utf-8 in strings + - [ ] Add caveats about utf-8 in tables * Introduction Python is a high-level, readable, interpreted language which can be used for many common computing tasks. It runs on most modern @@ -242,3 +244,51 @@ return 'images/python-matplot-fig.png' # return filename to org-mode #+end_example [[file:images/python-matplot-fig.png]] + +* Caveats + +** passing utf-8 strings to python + +You need some care in order to pass utf-8 strings to python. + +#+begin_example +#+NAME: unicode_str +,#+BEGIN_EXAMPLE +“this string is not ascii!” +,#+END_EXAMPLE +#+end_example + +#+begin_example +#+NAME: error-in-passing-var +#+BEGIN_SRC python :var data=unicode_str +return data +#+END_SRC +#+end_example + +#+begin_example +#+RESULTS: error-in-passing-var +#+end_example + +Will produce no output and prints the following message in the buffer +=*Org-Babel Error Output*=: + +#+BEGIN_EXAMPLE + File "", line 3 +SyntaxError: Non-ASCII character '\xe2' in file on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details +#+END_EXAMPLE + +** passing utf-8 strings to python with workaround + +A workaround is to use =:preamble= with wthe value =# -*- coding:utf-8 -*-= + +#+begin_example +#+NAME: ok-in-passing-var +#+BEGIN_SRC python :preamble "# -*- coding: utf-8 -*-" :var data=unicode_str +return data +#+END_SRC +#+end_example + +#+begin_example +#+RESULTS: ok-in-passing-var +: “this string is not ascii!” +#+end_example -- 2.1.4
[O] org-mode, python and unicode
Hello, I found some problems and workarounds in the use of python (version 2) and org-mode. This applies to: #+BEGIN_EXAMPLE Org-mode version 8.3.4 (8.3.4-60-g19cf68-elpa @ /home/vagrant/.emacs.d/elpa/org-20160516/) #+END_EXAMPLE Some workaround are not complete, and suggestions are welcome! Best, Daniele * python ** load python support for babel #+BEGIN_SRC emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((python . t))) #+END_SRC #+RESULTS: : ((python . t)) ** passing utf-8 strings to python #+NAME: unicode_str #+BEGIN_EXAMPLE “this string is not ascii!” #+END_EXAMPLE #+NAME: error-in-passing-var #+BEGIN_SRC python :var data=unicode_str return data #+END_SRC #+RESULTS: error-in-passing-var Will result in the following message in the buffer =*Org-Babel Error Output*=: #+BEGIN_EXAMPLE File "", line 3 SyntaxError: Non-ASCII character '\xe2' in file on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details #+END_EXAMPLE ** passing utf-8 strings to python with workaround A workaround is to use =:preamble= with wthe value =# -*- coding:utf-8 -*-= #+NAME: ok-in-passing-var #+BEGIN_SRC python :preamble "# -*- coding: utf-8 -*-" :var data=unicode_str return data #+END_SRC #+RESULTS: ok-in-passing-var : “this string is not ascii!” ** passing utf-8 tables to python #+NAME: unicode_table | key | value | |-+-| | 1 | “this string is not ascii!” | #+NAME: error-in-passing-table #+BEGIN_SRC python :var data=unicode_table return data #+END_SRC Will result in the following message in the buffer =*Org-Babel Error Output*=: #+BEGIN_EXAMPLE File "", line 3 SyntaxError: Non-ASCII character '\xe2' in file on line 3, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details #+END_EXAMPLE ** returning utf-8 tables from python #+NAME: error-in-returnig-table #+BEGIN_SRC python :preamble "# -*- coding: utf-8 -*-" :var data=unicode_table :colnames yes return data #+END_SRC Will output the ascii text with escape sequence for unicode characters. I still do not know the best workaround #+RESULTS: error-in-returnig-table | key | value | |-+---| | 1 | \xe2\x80\x9cthis string is not ascii!\xe2\x80\x9d | Please note that the single cell is correctly returned: #+NAME: returnig-table-cell #+BEGIN_SRC python :preamble "# -*- coding: utf-8 -*-" :var data=unicode_table return data[0][1] #+END_SRC #+RESULTS: returnig-table-cell : “this string is not ascii!” ** Undocumented parts I did not found out: - how to get the table headers in python - in general, the magic that org-mode does to pass and retrieve data structures to various languages is lacking documentation
Re: [O] Division of Org documentation: Org manual and Worg
On Wed, May 18 2016, Karl Voit wrote: > Good morning William, > > * William Henney wrote: >> >> On Tue, May 17, 2016 at 9:54 AM, Karl Voit wrote: >> >>> * William Henney wrote: >>> > >>> > #+BEGIN_SRC python :python /Users/will/anaconda/envs/py27/bin/python >>> >>> Is this undocumented? http://orgmode.org/org.html does not contain >>> the string ":python:" and >>> http://orgmode.org/org.html#Language_002dspecific-header-arguments >>> also does not mention this parameter. >>> >> It is documented at >> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-python.html >> >> You are right that it would be better if the language-specific babel >> documentation were better integrated in the general org info file. But I >> suppose nobody has been sufficiently motivated to do it yet > > That brings me to an additional question I was asking myself a > couple of times: things like this, IMHO basic features, are > sometimes mentioned in Worg but not in the Org manual. Is there a > «rule» that I can follow so that I know where to look? > > So far, I had to do full text search on both domains to find certain > keywords... Hello, Me too, and this is really a problem when you try do unusual stuff. I will share some problems and workaround for python in a new thread. It would be nice to add them to the documentation, but I have not yet figured out what is the appropriate way to send the patch! Best, Daniele
Re: [O] babel result chain outdated/inconsistent using var
On Thu, Apr 07 2016, Nicolas Goaziou wrote: > Daniele Pizzolli writes: > >> Do I am missing something else? Thanks again for your assistance. > > There seems to be an issue with cache. Call `M-x > org-element-reset-cache' before calling `org-babel-execute-buffer'. Hello, thanks, to be precise this is required to be iterated for every empty (without result output) named result block (if they are in chain) in the buffer. Not straightforward but I can live with that workaround. Once all the result block are populated, `M-x org-babel-execute-buffer' updates the results in a consistent way without the need of `M-x org-element-reset-cache' call. Thanks Nicolas for your support, Daniele
Re: [O] babel result chain outdated/inconsistent using var
On Thu, Apr 07 2016, Nicolas Goaziou wrote:
> Hello,
>
> Daniele Pizzolli writes:
>
>> #+NAME: pid-result
>> #+RESULTS: pid
>> #+NAME: echo-pid
>> #+BEGIN_SRC shell :var DATA=pid-result :results value
>> printf '%s' "${DATA}" #+END_SRC
>>
>> #+RESULTS: echo-pid
>
> You are giving two names to the block, which is not possible.
Hello,
Sorry for the confusion, I deleted one line more than the result ones.
I guess a new line or a comment or a text is enough to separate the
blocks.
> I don't know what you are trying to do here but you seem to confuse
> blocks with their results. They can be named independently.
I copied your example without the results, here is the updated
version, and even with a comment between the block produces the same
error `(error "Reference `pid-result' not found in this buffer")'
after calling `org-babel-execute-buffer'
#+NAME: pid
#+BEGIN_SRC shell :results value :cache no
printf '%s' "${$}"
#+END_SRC
#+NAME: pid-result
#+RESULTS: pid
# Some comment is required here to separate blocks, but it does not
# work either
#+NAME: echo-pid
#+BEGIN_SRC shell :var DATA=pid-result :results value
printf '%s' "${DATA}"
#+END_SRC
#+RESULTS: echo-pid
Do I am missing something else? Thanks again for your assistance.
Daniele
Re: [O] babel result chain outdated/inconsistent using var
On Wed, Apr 06 2016, Nicolas Goaziou wrote:
> Daniele Pizzolli writes:
>
>> Thanks Nicolas for the reply. Ok, but `org-babel-execute-buffer'
>> produces an inconsistent document right now.
>
> This is because you ask it to. See below.
>
>> Mmm, the same reasoning can be used for arguing about the current
>> behaviour: If I C-c C-c on a block, I expect only the code of the
>> block to be executed, not some other part of the document I am
>> editing. This behaviour will fix my issue.
>
> You are explicitly asking for a re-execution of a remote source block:
>
> :var DATA=pid
>
> If you are only interested in the results, you should name them, and use
> that instead, e.g.
Hello,
Oh, thanks Nicolas for the tip. But it does not work in a reliable
manner.
Calling `org-babel-execute-buffer' in the following snippet, raises:
(error "Reference `pid-result' not found in this buffer")
#+NAME: pid
#+BEGIN_SRC shell :results value :cache no
printf '%s' "${$}"
#+END_SRC
#+NAME: pid-result
#+RESULTS: pid
#+NAME: echo-pid
#+BEGIN_SRC shell :var DATA=pid-result :results value
printf '%s' "${DATA}"
#+END_SRC
#+RESULTS: echo-pid
Using the C-c C-c on the blocks also does not work... unless you also
do a C-c C-c on `#+NAME: pid-result' which is cumbersome if you have a
chain of blocks and results. Do you think that this can be fixed
easily?
Thanks in advance,
Daniele
Re: [O] babel result chain outdated/inconsistent using var
On Wed, Apr 06 2016, Nicolas Goaziou wrote:
> Hello,
>
> Daniele Pizzolli writes:
>
>> is possible to update the “#+RESULTS: pid” when the block “#+NAME:
>> echo-pid” is evaluated in the following snippet?
>
> Without `org-babel-execute-buffer', I don't think so.
Hello,
Thanks Nicolas for the reply. Ok, but `org-babel-execute-buffer'
produces an inconsistent document right now.
>> This will lead to a consistent document generation with “M-x
>> org-babel-execute-buffer” or by hitting “C-c C-c” on “#+NAME:
>> echo-pid”.
>
> I'm not convinced that this behaviour should be enforced. If I C-c C-c
> on a block, I expect only the results of the block to be updated, not
> some other part of the document I am editing.
Mmm, the same reasoning can be used for arguing about the current
behaviour: If I C-c C-c on a block, I expect only the code of the
block to be executed, not some other part of the document I am
editing. This behaviour will fix my issue.
I agree that neither case should be enforced, but the user should be
in charge to choose. A reasonable default behaviour will be to not
re-execute the other code block if the previous result is already
present.
> Also, what if the other block is in another document? I don't think it
> should be updated either.
But should it be either executed?
> What is the harm in using `org-babel-execute-buffer' for your use case?
Right now it does not produce a consistent document, that should be
desirable.
I do not have a strong preference about the solution (reuse without
re-execute, or update the other result) but for sure, right now there
is no way to produce a consistent document.
I tried for a workaround, adding `:eval query'
#+NAME: pid
#+BEGIN_SRC shell :results value :cache no :eval query
printf '%s' "${$}"
#+END_SRC
and then discarding the execution, but instead of reusing the actual
result it pass `nil'... no luck.
Thanks again,
Daniele
[O] babel result chain outdated/inconsistent using var
Hello,
is possible to update the “#+RESULTS: pid” when the block “#+NAME:
echo-pid” is evaluated in the following snippet?
This will lead to a consistent document generation with “M-x
org-babel-execute-buffer” or by hitting “C-c C-c” on “#+NAME:
echo-pid”. Using the cache does not make sense: the process is
generating different output every time.
The info at “M-: (info "(org) Specific header arguments")” does not
mention something useful.
* Intro
** pid
#+NAME: pid
#+BEGIN_SRC shell :results value :cache no
printf '%s' "${$}"
#+END_SRC
The following result is usually outdated/inconsistent!
#+RESULTS: pid
: 25272
** echo pid
#+NAME: echo-pid
#+BEGIN_SRC shell :var DATA=pid :results value
printf '%s' "${DATA}"
#+END_SRC
#+RESULTS: echo-pid
: 25273
The code block in pid is evaluated every time, but the results are
used only to populate the pid variable and non for updating the
results in the buffer:
#+BEGIN_EXAMPLE
executing Shell code block (pid)...
Wrote /tmp/babel-4889iZN/ob-input-4889CyZ
"25273"
executing Shell code block (echo-pid)...
Wrote /tmp/babel-4889iZN/ob-input-48892ay
Code block evaluation complete.
#+END_EXAMPLE
This was tested with Org-mode version 8.3.4 release_8.3.4-705-g716e33.
Thanks in advance for your suggestions,
Daniele
Re: [O] [PATCH] ox-koma-letter.el: Add support for section
On Mon, Jan 04 2016, Rasmus wrote: > Hi Daniele, > > Daniele Pizzolli writes: > >> thanks for you comment. I try to explain my point of view better. Now >> the export to letter silently discard the headings text in the exported >> tex. This is quite bad, even if documented. As a user I want to change >> quite easily the export backend (text, latex, beamer, ...) while >> retaining most of my work. Every backend as it's own supported >> features, but discarding the input provided by the user does not provide >> the best user experience to me. > > That's a fair point. Nonetheless, Hi Rasmus, thanks for recognizing it. >> By the way this patch does not change the final output, if there is no >> section.lco available. So there should be no regression and only >> improvements. > >> I really prefer something that instead of discarding the user input >> rewrite it to fit the backend features (if there is no heading/section >> support, use something like the start of paragraph, and support section >> only if enabled by the user) but this is beyond my coding abilities in >> elisp, so I sent the minimal working patch with the minimal impact on >> existing behaviour. > > > Whether sections.lco is available is nontrivial. As I remember the patch, > it also imposed level two headings to be sections. Not really. With the current patch, all the headings inside the main content (that is the first not special tagged heading) are rendered with a section level that is one level more than expected because the first level is taken away by the main content (because the main content is not a section). So there should be some work to adjust the level by adding +1. The behaviour of one level headings is left unchanged because of the way ox-koma-letter works, but this can be changed, if there is a better approach. > If you really think this is the right approach, perhaps the "H:" option > could be used to set the special heading level... We’d need this since > you can specify the opening with a heading. I am lost here. H: should work as expected. We have the inverse problem (go up to the level with sections). >>>> +Add [sections] to LATEX_CLASS_OPTIONS with: >>>> + >>>> +#+LATEX_CLASS_OPTIONS: [sections] >>>> + >>>> +If section.lco is unavaliable the section are exported in the tex >>>> +source but not rendered in the final pdf. >>> >>> Whether section.lco is available or not is a complicated question. You >>> first need to figure out what is the tex distribution (what if it’s not in >>> PATH) and whether section.lco is available via something like kpsewhich. >>> Note that e.g. TL also looks in the current path. >> >> I use org to touch as less latex as possible, I just downloaded the >> section.lco and put in the same directory of my org file and everything >> was working. A little before I used apt-file search section.lco but >> since nothing was found I quickly reverted to the manual download. I >> wish that everything is packaged as distro package, but I can survive >> some manual work. > > This is because sections.lco is not part of KOMA-Script (like titlepage¹). > E.g. on my system with TL: > > $ kpsewhich sections.lco > /home/rasmus/.texmf/tex/latex/koma-script/sections.lco > > kpsewhich/tex also looks in the current directory, which is why you can > just place it in the same folder. Thanks for the info, I admit that LT and kpsewhich are unknown to me, as I said I try to stay away from latex and tex as much as possible. If there is some agreement on the patch I will update the doc to add those info. Best, Daniele
Re: [O] [PATCH] Fix typo
On Sun, Jan 03 2016, Nicolas Goaziou wrote: > Hello, > > Daniele Pizzolli writes: > >> Fix a typo. > > Applied. Thank you. Hello Nicolas, Thanks to you for this and for all your effort in improving org-mode! > BTW, have you signed the FSF papers? I thought you already had provided > some patches, but I was apparently wrong. No, never signed the paper. This is in contrib, so signing the FSF should be not mandatory. Yes, I sent some patches, most of them as draft or suggestions, but none went merged unmodified, some went merged with some rewriting. Anyway I will not give up and at some point in the future I hope to send something good enough! Best, Daniele
Re: [O] [PATCH] ox-koma-letter.el: Add support for section
On Sat, Jan 02 2016, Rasmus wrote: > Hi Daniele, > > First, thanks for your patch. > > Daniele Pizzolli writes: > >> I was really surprised that headlines, that are so common in org-mode >> are discarded by default in ox-koma-letter. > > Why? They are not supported by scrlttr2.cls, except if you download an > extra lco file, not distributed via CTAN. As such, I don’t think it > should be supported by ox-koma-letter.el. Hello Rasmus, thanks for you comment. I try to explain my point of view better. Now the export to letter silently discard the headings text in the exported tex. This is quite bad, even if documented. As a user I want to change quite easily the export backend (text, latex, beamer, ...) while retaining most of my work. Every backend as it's own supported features, but discarding the input provided by the user does not provide the best user experience to me. By the way this patch does not change the final output, if there is no section.lco available. So there should be no regression and only improvements. I really prefer something that instead of discarding the user input rewrite it to fit the backend features (if there is no heading/section support, use something like the start of paragraph, and support section only if enabled by the user) but this is beyond my coding abilities in elisp, so I sent the minimal working patch with the minimal impact on existing behaviour. > A general headline property that allows to insert arbitrary code right > before a headline (such as "@@latex:\clearpage@@") might be a more > fruitful approach. I guess this is another story. >> +Add [sections] to LATEX_CLASS_OPTIONS with: >> + >> +#+LATEX_CLASS_OPTIONS: [sections] >> + >> +If section.lco is unavaliable the section are exported in the tex >> +source but not rendered in the final pdf. > > Whether section.lco is available or not is a complicated question. You > first need to figure out what is the tex distribution (what if it’s not in > PATH) and whether section.lco is available via something like kpsewhich. > Note that e.g. TL also looks in the current path. I use org to touch as less latex as possible, I just downloaded the section.lco and put in the same directory of my org file and everything was working. A little before I used apt-file search section.lco but since nothing was found I quickly reverted to the manual download. I wish that everything is packaged as distro package, but I can survive some manual work. Best, Daniele
[O] [PATCH] ox-koma-letter.el: Add support for section
Hello, I was really surprised that headlines, that are so common in org-mode are discarded by default in ox-koma-letter. This patch tries to add the support for them. It works for me but requires some work to fit the coding and documentation convention that are still unknown to me. I will be happy to follow your suggestion or if somebody take this code as a minimal implementation to start to work with. Thanks in advance, Daniele >From 390d93afc95f6151e1bde43ef91b4e31f91ecd01 Mon Sep 17 00:00:00 2001 From: Daniele Pizzolli Date: Sat, 2 Jan 2016 11:48:24 +0100 Subject: [PATCH] ox-koma-letter.el: Add support for section * contrib/lisp/ox-koma-letter.el (org-koma-letter-headline): Add support for section using the text of headline. TINYCHANGE --- contrib/lisp/ox-koma-letter.el | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index 3231d34..aea5a9c 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -569,10 +569,34 @@ holding contextual information. Note that if a headline is tagged with a tag from `org-koma-letter-special-tags' it will not be exported, but stored in `org-koma-letter-special-contents' and included at the -appropriate place." +appropriate place. + +If the headline level is greater than one include the headline as +section. This allow to write letter with sections by using +section.lco available at: +<http://www.komascript.de/sections.lco>. + +Add [sections] to LATEX_CLASS_OPTIONS with: + +#+LATEX_CLASS_OPTIONS: [sections] + +If section.lco is unavaliable the section are exported in the tex +source but not rendered in the final pdf. + +- TODO: add test +- TODO: level n should become n-1, because there is no real +level 1 section +- TODO: check if section are allowed inside other letter keywords +" (let ((special-tag (org-koma-letter--special-tag headline info))) (if (not special-tag) - contents + (progn + (if (= 1 (org-element-property :level headline)) + contents + (progn + ;; TODO find out how to decrease the level by one! + (org-latex-headline headline contents info) + ))) (push (cons special-tag contents) org-koma-letter-special-contents) ""))) -- 2.1.4
[O] [PATCH] ox-koma-letter.el: Add support for section
Hello, I was really surprised that headlines, that are so common in org-mode are discarded by default in ox-koma-letter. This patch tries to add the support for them. It works for me but requires some work to fit the coding and documentation convention that are still unknown to me. I will be happy to follow your suggestion or if somebody take this code as a minimal implementation to start to work with. Thanks in advance, Daniele >From 390d93afc95f6151e1bde43ef91b4e31f91ecd01 Mon Sep 17 00:00:00 2001 From: Daniele Pizzolli Date: Sat, 2 Jan 2016 11:48:24 +0100 Subject: [PATCH] ox-koma-letter.el: Add support for section * contrib/lisp/ox-koma-letter.el (org-koma-letter-headline): Add support for section using the text of headline. TINYCHANGE --- contrib/lisp/ox-koma-letter.el | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index 3231d34..aea5a9c 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -569,10 +569,34 @@ holding contextual information. Note that if a headline is tagged with a tag from `org-koma-letter-special-tags' it will not be exported, but stored in `org-koma-letter-special-contents' and included at the -appropriate place." +appropriate place. + +If the headline level is greater than one include the headline as +section. This allow to write letter with sections by using +section.lco available at: +<http://www.komascript.de/sections.lco>. + +Add [sections] to LATEX_CLASS_OPTIONS with: + +#+LATEX_CLASS_OPTIONS: [sections] + +If section.lco is unavaliable the section are exported in the tex +source but not rendered in the final pdf. + +- TODO: add test +- TODO: level n should become n-1, because there is no real +level 1 section +- TODO: check if section are allowed inside other letter keywords +" (let ((special-tag (org-koma-letter--special-tag headline info))) (if (not special-tag) - contents + (progn + (if (= 1 (org-element-property :level headline)) + contents + (progn + ;; TODO find out how to decrease the level by one! + (org-latex-headline headline contents info) + ))) (push (cons special-tag contents) org-koma-letter-special-contents) ""))) -- 2.1.4
[O] [PATCH] Fix typo
Fix a typo. Best, Daniele >From 09f2c70f4e95a9489279b3b3989a2244703bc9c9 Mon Sep 17 00:00:00 2001 From: Daniele Pizzolli Date: Sat, 2 Jan 2016 11:25:15 +0100 Subject: [PATCH] Fix typo --- contrib/lisp/ox-koma-letter.el | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/lisp/ox-koma-letter.el b/contrib/lisp/ox-koma-letter.el index aad0672..3231d34 100644 --- a/contrib/lisp/ox-koma-letter.el +++ b/contrib/lisp/ox-koma-letter.el @@ -80,9 +80,9 @@ ;; `org-koma-letter-special-tags-after-closing' used as macros and the ;; content of the headline is the argument. ;; -;; Headlines with two and from may also be used rather than the -;; keyword approach described above. If both a keyword and a headline -;; with information is present precedence is determined by +;; Headlines with to and from may also be used rather than the keyword +;; approach described above. If both a keyword and a headline with +;; information is present precedence is determined by ;; `org-koma-letter-prefer-special-headings'. ;; ;; You need an appropriate association in `org-latex-classes' in order -- 2.1.4
Re: [O] html export list of figures
On Thu, Sep 24 2015, John Kitchin wrote: [] Hello, I am reversing the conversation to figure out the meaning: > > In org-ref I provide a list-of-tables and list-of-figures link, > > which has the latex [] >> Great John, thanks, I will see what I can add. Is this package part >> of any library available via that package manager? [] > no, for now it is still only available on github. Well, I made a recipe for el-get some time ago. Best, Daniele
Re: [O] "Capture"-like browser plugin?
On Thu, Sep 17 2015, Samuel Wales wrote: > On 7/23/15, Daniele Pizzolli wrote: >> https://addons.mozilla.org/it/firefox/addon/org-mode-capture/ >> >> The latest version convert html links to org-links (disclaimer: it is my >> little contribution). > > this extension is wonderful. all you have to do is install it and > then do what you want with it in elisp. i use it with iceweasel > 40.0.3 (rebranded firefox). Hello Samuel, Nice to hear. > however, it (or org-protocol) is very flaky. it works half of the > time, but sometimes it will do nothing and say "No server buffers > remain to edit" So, not so wonderful.. I just found out how to reproduce this problem. Open a page with two frames, for example: http://www.quackit.com/html/templates/download/preview.cfm?template=../frames/css_frames/frames_2_column_left_menu.cfm And pressing C-a (Select All) for the selection. And then capture the page. Please note that you can not select the text in both frames using the mouse. > and sometimes it will capture the link but not the > selection. Do you have an example page for this? Once we have a really simple example page with the error we can report a bug! > it will also sometimes capture something else you copied, > which does not appear on the page whose link gets capture. Yes, I saw a note in the code, the /problem/ is that firefox does not clean the selection when you change tab. So you select something in tab 1, switch to tab 2 and you get the link and page title of page 2 and the selection of tab 1. Maybe there are workaround, like force the cleaning of the selection after a tab change, but this can impact the user experience. I guess that usually you expect the selection to persist until you paste it, even if you have changed tab, or not? Coping from tab 1 and paste in tab 2 is not an exotic use case. I think that the selection is global and not per tab. Maybe is possible to add a selection per tab, by listening to some events. Another limitation of the selection in firefox is that can not span over frames and over 3rd party injection of content (not sure on how they do this those days) but in a page with content and disqus.com you can not select and capture both with the mouse. And if you use C-a you will bump into the previous problem. Hope you find this information useful, Daniele
Re: [O] "Capture"-like browser plugin?
On Tue, Jul 28 2015, Peter Davis wrote: > Daniele Pizzolli writes: > >> On Thu, Jul 23 2015, Peter Davis wrote: [] >> >> https://addons.mozilla.org/it/firefox/addon/org-mode-capture/ >> > > Thank you, Daniele. I'm afraid I haven't been able to get this to work on a > Mac. I have the Firefox add-in installed, and emacs > configured, but when I click the icon, nothing (seems to) happen(s). Hello Peter, I did most of the development months ago and I do not remember a lot. By looking at the mozilla doc[1] you should be find some pointer on how to enable logging/debugging for extensions. The line where emacs is launched is at [2]. I do not know a lot of Mac, maybe you miss the emacsclient command or PATH? Maybe the run() at [2] does not work on Mac? A manual test would be to execute on a console something like: emacsclient 'org-protocol://capture://https%3A%2F%2Fdeveloper.mozilla.org%2Fen-US%2FAdd-ons%2FSDK%2FTools%2Fconsole%23Logging_Levels/console%20-%20Mozilla%20%7C% 20MDN/console' If the latter does work the problem should be in the run() call. Hope this helps, Daniele [1] https://developer.mozilla.org/en-US/Add-ons/Setting_up_extension_development_environment [2] http://hub.darcs.net/oschwand/firefox-org-capture/browse/lib/main.js#156
Re: [O] "Capture"-like browser plugin?
On Thu, Jul 23 2015, Peter Davis wrote: > Frequently when I'm doing a Web search and find pages I like, I want > to save a link to the page, along with the title and perhaps a few > notes. Something like org-mode's capture would be great, but I'd like > to initiate it from a browser. I imaging hitting a plugin button on > the the browser's toolbar to open emacs via emacsclient, and > essentially do a capture with the link and whatever text I care to > enter. > > Has anyone seen or heard of or written something like this? Hello, if you use firefox, see: https://addons.mozilla.org/it/firefox/addon/org-mode-capture/ The latest version convert html links to org-links (disclaimer: it is my little contribution). You described what org-capure does so well that I am surprised you where not able to find it! Some weeks ago something similar for chrome was announced here in the list. You may want to search into the archives. Best, Daniele
Re: [O] Bug: It's not obvious how to keep LocalWords (spelling exceptions) conveniently [8.2.10 (release_8.2.10 @ /usr/share/emacs/24.4/lisp/org/)]
On Tue, Jun 30 2015, Nicolas Goaziou wrote: > Hello, > > Reuben Thomas writes: > > Disclaimer: I don't know what are "LocalWords" and I could find > a reference either in the Emacs or Elisp manual. Hello, In fact it is not so easy to find it! There are too many way to search in emacs and there is not an universal one (I guess). If you have reasonable defaults the following should work: M-x apropos-value RET LocalWords and should point to: ispell-words-keyword Best, Daniele
[O] BUG: named time references problem in formula
Hello, according to [[info:org#References]] (see Named references) is possible to use a property in formulas. This generally works, but not when the property is a time value as defined in [[info:org#Durations%20and%20time%20values]]. Please have a look at the following ECM: * test table with constant (working) :PROPERTIES: :constant: 3 :END: | month | days | results | |---+---+-| |01 | 1 | 3 | |02 | 3 | 9 | #+TBLFM: $3=$2*$PROP_constant; * test table with time constant (not working) :PROPERTIES: :time_constant: 08:00:00 :END: | month | days | time | |---+--+--| |01 |1 | | |02 |3 | | #+TBLFM: $3=$2*$PROP_time_constant;T Pressing C-u C-c C-c over the table shows in the message buffer: org-table-eval-formula: Wrong type argument: stringp, (13 "Bad format") Also is not possible to debug the code even with the formula debug enabled. Omitting the ";T" part will cause the debug to work and then the string #ERROR show up in the cell. My version is Org-mode version 8.3beta (release_8.3beta-1080-g367d48 @ /home/user/.emacs.d/el-get/org-mode/lisp/) Best, Daniele
Re: [O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
Nicolas Goaziou writes: > Hello, [] > Indeed. This should be fixed in > ad7b7efcdc2e0803cbf0257bb2588c8e8e1cac29. > > If fall-backs to a plain string. > > Thank you. Thanks to you for taking care so quickly! Best, Daniele
Re: [O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
John Kitchin writes: > I am pretty sure this is a long-standing "feature". > > Try this: > #+BEGIN_SRC emacs-lisp :results raw > (org-babel-do-load-languages > 'org-babel-load-languages > '((emacs-lisp . nil) > (R . t))) > #+END_SRC > > I have never been able to use a babel block that outputs a list of cons > cells without explicitly setting results to raw or code. The problem > here is your code evaluates to ((emacs-lisp) (R . t)), and the t somehow > gets interpreted like it should be a list, which it is not. So, it > cannot be made into a table for output, and you get your error. > > Changing the header just bypasses this function and outputs the results > more directly. Hello John, thanks for the explanation. Unfortunately my lisp knowledge is too limited to understand you. As a naive org-mode user, if possible I do not want to be exposed to org internals error, especially the confusing ones, where the custom code works fine. Maybe we can get a warning instead of an error? It is not a really big issue, a newcomer can be confused, if not scared, having an error on the fist babel usage. Best, Daniele
[O] [BUG] shell not working as sh?
Hello, I remember that sh was renamed to shell some time ago. But shell sometimes does not work, while sh does. Is there a difference between the two (and when i should use one over another?) or is it a bug? The minimal example follows: #+PROPERTY: header-args:shell :dir /vagrant@127.0.0.1:/vagrant #+PROPERTY: header-args:shell+ :exports both :results output verbatim replace #+PROPERTY: header-args:sh :dir /vagrant@127.0.0.1:/vagrant #+PROPERTY: header-args:sh+ :exports both :results output verbatim replace * setup #+BEGIN_SRC sh cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keys # TODO accept the host key automatically or use StrictHostKeyChecking no # not sure if tramp is smart enough to handle this by default #+END_SRC #+BEGIN_SRC emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . t) (python . t) (shell . t) (sh . t))) #+END_SRC #+RESULTS: #+RESULTS: * sh works #+BEGIN_SRC sh ls | wc -l #+END_SRC #+RESULTS: : 5 * shell does not work #+BEGIN_SRC shell ls | wc -l #+END_SRC Will show in *Messages* org-babel-execute:shell: Wrong number of arguments: #[(session body &optional params stdin) [... binary code cut ...] * org version #+BEGIN_SRC emacs-lisp (org-version nil t) #+END_SRC #+RESULTS: : Org-mode version 8.3beta (release_8.3beta-860-ge4da74 @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/) Best, Daniele
[O] [BUG] babel eval of emacs-lisp: orgtbl-to-orgtbl: Wrong type argument: listp, t
Hello, my attempt to use org-mode for both interactive presentation and final report was unsuccessful due to a series of bugs and nuisances. Fortunately I can use the result of tangle. Will report the issues encountered to the list in the next few days. Here is a minor one. The following code, taken from [[info:org#Languages]] works if run after manually selecting it and running with M-x eval-region. But with M-x org-babel-execute-src-block it triggers an error. The *Messages* buffer shows: #+BEGIN_EXAMPLE executing Emacs-Lisp code block... orgtbl-to-orgtbl: Wrong type argument: listp, t #+END_EXAMPLE #+BEGIN_SRC emacs-lisp (org-babel-do-load-languages 'org-babel-load-languages '((emacs-lisp . nil) (R . t))) #+END_SRC #+BEGIN_SRC emacs-lisp (org-version nil t) #+END_SRC #+RESULTS: : Org-mode version 8.3beta (release_8.3beta-860-ge4da74 @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/) Best, Daniele
Re: [O] control tangling from section header
Hello Ken, Ken Mankoff writes: > I'm working with my literate init file (emacs.org), and would like to > have certain sections not tangle. I currently do this with ":tangle no" > at the SRC block level. Is it possible to control tangling with tags at > the header level? Not with tag but with PROPERTIES: * outline header :PROPERTIES: :header-args: :tangle no :END: More at http://orgmode.org/manual/Header-arguments-in-Org-mode-properties.html > It would make it much easier to disable/enable sections, and see what > sections are enabled/disabled, if the tangling state were more clearly > visible like tags are. I do not think that this is currently possible. Best, Daniele
[O] [BUG] babel hangs executing some shell commands in session
Hello, I am going to give an interactive presentation of git using org-mode and babel. But I am stuck with random hangs when executing the code with =C-c C-c= and during export. I am using Org-mode version 8.2.4 (8.2.4-dist @ /home/vagrant/.emacs.d/el-get/org-mode/lisp/) The hangs does not always happen, but if you execute the following code blocks a couple of times you should ran into the problem. Assumption: the file =/etc/sudoers= contains something like "vagrant ALL=(ALL) NOPASSWD:ALL" to not ask password with an interactive prompt. #+PROPERTY: header-args:shell :session *git-shell* :dir /vagrant #+PROPERTY: header-args:shell+ :exports both :results output verbatim replace #+PROPERTY: header-args:shell+ :tangle git_demo.sh :shebang "#!/bin/bash" :comments org #+BEGIN_SRC shell sudo apt-get remove --purge --yes git && sudo apt-get autoremove --yes #+END_SRC #+BEGIN_SRC shell sudo apt-get install --yes git #+END_SRC My guess, by looking at the *git-shell* buffer after waiting a minute and hitting C-g, is that the output of echo 'org_babel_sh_eoe' sometimes is eaten by some ansi sequence of the interactive command. See for example the following cut and paste from the *git-shell* buffer. Do babel do something nasty with the shell/term emulator? #+begin_example vagrant@git-pratical:/vagrant$ sudo apt-get remove --purge --yes git && sudo apt-get autoremove --yes Reading package lists... 0%echo 'org_babel_sh_eoe' Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: git-man liberror-perl Use 'apt-get autoremove' to remove them. The following packages will be REMOVED: git* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 22.2 MB disk space will be freed. (Reading database ... 122644 files and directories currently installed.) Removing git (1:2.3.0-0ppa1~ubuntu12.04.1) ... Purging configuration files for git (1:2.3.0-0ppa1~ubuntu12.04.1) ... Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: git-man liberror-perl 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. After this operation, 1,477 kB disk space will be freed. (Reading database ... 122040 files and directories currently installed.) Removing git-man (1:2.3.0-0ppa1~ubuntu12.04.1) ... Removing liberror-perl (0.17-1.1) ... Processing triggers for man-db (2.6.7.1-1ubuntu1) ... vagrant@git-pratical:/vagrant$ #+end_example An indirect confirmation of my guess comes from a test: redirecting the output of the command and then printing it. Using this workaround babel never hangs: #+BEGIN_SRC shell (any_strange_command) 1>/tmp/1 2>/tmp/2; cat /tmp/1 /tmp/2 #+END_SRC Do you think that is easy to fix babel or can you suggest a less invasive and more comprehensive workaround? Wrapping loops and pipes is going to clutter the code to the point that is better to use a script with inline comments rather that using the org-mode buffer. Thanks in advance, Daniele
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
Hello Charles, "Charles C. Berry" writes: > Further Daniele's response to '[bug] Removing the Babel results': > > http://article.gmane.org/gmane.emacs.orgmode/94604 > > See below. > >> But why a `native' function? You know how to achieve this result and >> can >> >> 1. add a customized function to your init file, >> 2. submit a snippet to Worg, and/or >> 3. contribute an *add on*, and/or >> 4. argue for changes/additions to the Org code base, what you call a >> `native' function. >> >> Option 4 generates work for those who maintain Org code, so it needs >> to be justified in terms of usefulness to other users and >> issues in the code that it might fix or complicate. >> >> Even if 4 is the right path, a decision is needed on whether to add >> new functions, or change the behavior of existing functions (possibly >> adding a new variable or customization). The latter might be cleaner, >> but runs the risk of breaking someone's code. > > The latter notion is along these lines: Thanks for your reasoning and conclusion. > > #+BEGIN_SRC emacs-lisp >(defun org-babel-remove-result-one-or-many (x &optional keep-keyword) > "Remove the result of the current source block. >If called with a prefix argument, remove all result blocks and >results macros in the buffer. When KEEP-KEYWORD is non-nil, allow >RESULTS keywords to remain." > (interactive (list current-prefix-arg > (y-or-n-p "Keep RESULTS keyword(y/n):"))) (y/n) seems to be redundant: y-or-n-p prints the options by itself. > (if x > (org-babel-map-executables nil >(org-babel-remove-result nil keep-keyword) >(org-babel-remove-inline-result)) >(org-babel-remove-result nil keep-keyword) >(org-babel-remove-inline-result))) > #+END_SRC > > which seems to handle Sebastien's `bug' if the user responds with 'y' (or > a calling function has a non-nil `keep-keyword'. Seems reasonable to me. But I still think that one-or-many does not have a lot of sense since there is the one-case function already. Is it possible to call it by something like C-u C-u M-x org-babel-remove-result-one-or-many or by a custom keystroke and avoid the interactive prompt and have it to clean all the result keeping the keyword (without writing a function or using lambda)? As a novice I like interactive prompt because you can be lead through the choices, but I do not want to be annoyed by them when I become expert and have the answer ready and it is almost always the same one. If not, no worries, I think I will wrap in a custom one. Thanks again, Daniele
Re: [O] [bug] Removing the Babel results
Hello Sebastien, Sebastien Vauban writes: > Hello, > > Removing the Babel results (through `C-c C-v k') is not done in > a coherent way, as you can see in the following example: Nice to hear that I am not the only one to complaint. :-) I proposed a new function that preserve the placement of the result if you used named (keyword) block result, and hopefully does the right thing by default! Maybe this will help to get it merged or to continue the discussion and rearch some agreement. Feel free to comment at the previous thread: http://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00797.html http://lists.gnu.org/archive/html/emacs-orgmode/2015-01/msg00814.html Thanks, Daniele
Re: [O] traling whitespace inconsistency for inline babel
Hello Charles,
"Charles C. Berry" writes:
> On Sat, 31 Jan 2015, Daniele Pizzolli wrote:
>
>> Hello Charles,
>>
>> Thanks for fixing the leading whitespace issue.
>>
>> I found another, more impacting, inconsistency involving trailing
>> whitespace during export in release_8.3beta-780-g37fc86:
>>
>> The following line in org:
>>
>> 1 + 4 in R is src_R[:exports results]{1+4}.
>>
>> Export in latex correctly as:
>>
>> 1 + 4 in R is 5.
>>
>> while the following (with the babel result):
>>
>> 1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}}.
>>
>> export with an extra trailing whitespace in latex:
>>
>> 1 + 4 in R is 5 .
>
> Both are wrong for *latex*.
Yes, you are right. Thanks and sorry for the noise. A complete restart
of emacs fixed this. I made the previous test after an el-get-update
org-mode and org-reload. Maybe I misconfigured something.
> But I get
>
> 1 + 4 in R is \texttt{5}.
I also forgot to mention that there was no \texttt{} because of custom
setting: (setq org-babel-inline-result-wrap "%s"). Sure, now I have the
correct output.
> In both cases, and when I export to pdf I get `5.' (via copy and
> paste).
I used export to latex buffer (C-c C-e l L).
> I am using
>
> commit a752684bf0368ddea1f6480157e770c0dd57b7a5
> Author: Nicolas Goaziou
> Date: Sat Jan 31 12:46:50 2015 +0100
>
> which is the latest in master.
Now me too. Thanks again,
Daniele
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
Hello Charles, "Charles C. Berry" writes: > RFC: the patch to `org-babel-remove-inline-result-one-or-many' removes > inline results, too. > > Do you see any bad consequences? > > On Fri, 30 Jan 2015, Daniele Pizzolli wrote: > >> Hello Charles, >> >> "Charles C. Berry" writes: >> >>> On Fri, 30 Jan 2015, Daniele Pizzolli wrote: >>> > > [discussion of extra whitespace bug deleted] > > There is now a bugfix on master. I've also added 'interactive' to > `org-babel-remove-inline-result'. > >> >>>> Is there a way to evaluate a buffer an then remove inline results or >>>> better, to get the very same buffer after: >> > > Yes. > > See attached patch which should clean *all* results (except `raw' > results) from a buffer when `org-babel-remove-result-one-or-many' is > called with a prefix. > > Before pushing this, I'd like some feedback on the wisdom of doing > what the patch does. Let me try to explain better my use case, that is not covered by this patch, but was covered by mine. Currently org-babel-remove-result has an optional argument to keep the named block results at their position. I will call this feature clean-result. I think that this is more useful that the default remove-result. The rationale is that removing the results will lead to some inconsistencies if you remove and re-execute the buffer, for details see: http://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00872.html So I will be happy if a native function take care of this use case. Maybe a new function with clean in the name instead of remove will solve this? Or it will add additional confusion as the inline sources are removed but the blocks cleaned... Also, I do not really see the point of having org-babel-remove-result-one-or-many, since the one case is already covered by org-babel-remove-result, but maybe there is some additional magic that I do not understand. [skip the discussion about my previous patch] >> Patch attached. > > Thank you. > > Regarding patches, if you haven't signed FSF copyright papers a > TINYCHANGE is needed in the commit message. Yes, there was a TINYCHANGE in the last line of the commit message! Best, Daniele
[O] traling whitespace inconsistency for inline babel
Hello Charles,
Thanks for fixing the leading whitespace issue.
I found another, more impacting, inconsistency involving trailing
whitespace during export in release_8.3beta-780-g37fc86:
The following line in org:
1 + 4 in R is src_R[:exports results]{1+4}.
Export in latex correctly as:
1 + 4 in R is 5.
while the following (with the babel result):
1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}}.
export with an extra trailing whitespace in latex:
1 + 4 in R is 5 .
Thanks,
Daniele
Re: [O] idempotency and inconsistency for org-babel-remove-inline-result
Hello Charles,
"Charles C. Berry" writes:
> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>
>> Hello,
>>
>> I really like the new inline results. Thanks for this new cool feature.
>> I have only a few problems with it.
>>
>
> Thanks for your feedback.
Nice to hear.
>> Is there a way to evaluate a buffer an then remove inline results or
>> better, to get the very same buffer after:
[]
>> I see that the function docs says: Extraneous leading whitespace is
>> trimmed. Is this the intended result?
>
> It is intended to remove `extraneous' whitespace. But the way
> `extraneous' is operationalized leaves something to be desired if
> users wish to do as you have done. Maybe preserving whitespace (if any)
> after the result and deleting all that is before it might work.
>
> I'll take a look at changing the defn to deal with your ECM.
Thanks, see later.
>>
>> Also, is there anything that prevents to make
>> org-babel-remove-inline-result interactive as is
>> org-babel-remove-result?
>
> AFAICS, no.
Ok, patch attached.
>> Wwhy not have also
>> org-babel-remove-inline-result-one-or-many and
>> org-babel-remove-all-result-one-or-many to remove all the babel result
>> with one function call?
>
> Easy enough, but is this really needed? What about call block/line
> results?
This is useful for me because I want to easily discard the results to
have the commit with only the changes in the source. I hope others find
this a reasonable facility. It is like a 'make clean' for your org
files.
Patch attached. I am not sure about the default of discarding keyword
Deleting the result line can cause some disorder, but it is the default
in org-babel-remove-result. Also the naming can be confusing.
>> I do no not know lisp a lot, but I can try to submit a patch if you
>> agree that will be useful.
>>
>
> The main issue (IMO) is figuring out what whitespace to delete around
> a `{{{results(...)}}}' macro. I can get to this in a day or so, but
> feel free to send a patch.
This is above my lisp coding abilities, with too many org-related
function to get lost into org-babel-remove-inline-result... I can wait,
but if you have any pointer I will be happy to do some exploration.
Thanks again,
Daniele
>From 4f484ac1f9ae4adcf5551bf6e77e5545f124f11b Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli
Date: Fri, 30 Jan 2015 20:57:15 +0100
Subject: [PATCH 1/2] ob-core.el: add interactive to
`org-babel-remove-inline-result'
* lisp/ob-core.el (org-babel-remove-inline-result): Add interactive.
TINYCHANGE
---
lisp/ob-core.el | 1 +
1 file changed, 1 insertion(+)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index fcc44c1..ac9f63b 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2324,6 +2324,7 @@ INFO may provide the values of these header arguments (in the
"Remove the result of the current inline-src-block or babel call.
The result must be wrapped in a `results' macro to be
removed. Extraneous leading whitespace is trimmed."
+ (interactive)
(let* ((el (org-element-context))
(post-blank (org-element-property :post-blank el)))
(when (memq (org-element-type el) '(inline-src-block inline-babel-call))
--
2.1.4
>From b108f6b8dfd28d6c6ebcdfcabb428438fe348ad9 Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli
Date: Fri, 30 Jan 2015 23:28:27 +0100
Subject: [PATCH 2/2] ob-core.el: Add `org-babel-remove-result-all'
* lisp/ob-core.el (org-babel-remove-result-all): New interactive
function.
TINYCHANGE
---
lisp/ob-core.el | 10 ++
1 file changed, 10 insertions(+)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index ac9f63b..e09863d 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2348,6 +2348,16 @@ in the buffer."
(org-babel-map-src-blocks nil (org-babel-remove-result))
(org-babel-remove-result)))
+(defun org-babel-remove-result-all (x)
+ "Remove the results of all the source blocks and the results of all inline sources.
+If called with a prefix argument, keep the keyword in result
+blocks."
+ (interactive "P")
+ (if x
+ (org-babel-map-src-blocks nil (org-babel-remove-result nil t))
+(org-babel-map-src-blocks nil (org-babel-remove-result)))
+ (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result)))
+
(defun org-babel-result-end ()
"Return the point at the end of the current set of results."
(save-excursion
--
2.1.4
[O] idempotency and inconsistency for org-babel-remove-inline-result
Hello,
I really like the new inline results. Thanks for this new cool feature.
I have only a few problems with it.
Is there a way to evaluate a buffer an then remove inline results or
better, to get the very same buffer after:
(org-babel-execute-buffer)
(org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))
Every call add an extra white space:
Original:
1 + 4 in R is src_R[:exports results]{1+4}.
After (org-babel-execute-buffer):
1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}}.
After: (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))
1 + 4 in R is src_R[:exports results]{1+4} .
After (org-babel-execute-buffer):
1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}} .
And so on...
I see that the function docs says: Extraneous leading whitespace is
trimmed. Is this the intended result?
Also, is there anything that prevents to make
org-babel-remove-inline-result interactive as is
org-babel-remove-result? Wwhy not have also
org-babel-remove-inline-result-one-or-many and
org-babel-remove-all-result-one-or-many to remove all the babel result
with one function call?
I do no not know lisp a lot, but I can try to submit a patch if you
agree that will be useful.
Thanks in advance,
Daniele
Re: [O] OT: Gmail and cloud-dependencies
Karl Voit writes: > * Paul Rudin wrote: >> Karl Voit writes: >> > >>> * Paul Rudin wrote: [] >>> You'll lose some more. At least you are going to lose your labels >>> AFAIR. >> >> Labels map to mailboxes if you access your gmail via imap IIRC, so you >> don't really lose that information. > > AFAIR do you lose information for sure: you can't have combinations > of labels (e.g., +important+business) as mailboxes and you can't > export this information in a meaningful way for migration. Hello, I never used that but, offlineimap seems to be able to sync the labels using a custom(?) message header. See: https://github.com/OfflineIMAP/offlineimap/blob/fc4c7549d6d03415edc2537b29c83fd6baea1bc6/offlineimap/folder/Gmail.py#L67 I am not sure if that is really meaningful. Maybe mail clients like mu4e can be used to search this header in a way easy to use. Best, Daniele
Re: [O] Efficiency of Org v. LaTeX v. Word
Hello, Ken Mankoff writes: > People here might be interested in a publication from [2014-12-19 Fri] > available at http://dx.doi.org/10.1371/journal.pone.0115069 > > Title: An Efficiency Comparison of Document Preparation Systems Used > in Academic Research and Development > > Summary: Word users are more efficient and have less errors than even > experienced LaTeX users. As other said, the efficiency in the paper is about the manual copy of a small portion of text, tables... This is a little bit different to publish a research, maybe a reproducible one, with the help of a team. > Someone here should repeat experiment and add Org into the mix, perhaps > Org -> ODT and/or Org -> LaTeX and see if it helps or hurts. I assume > Org would trump LaTeX, but would Org -> ODT or Org -> X -> DOCX (via > pandoc) beat straight Word? Repeating a flawed experiment do not add a lot of value... Best, Daniele
Re: [O] Evaluating R source code line by line
Hello, Vikas Rawal writes: > I have an R source code blocks called with the ":results value” > option. I evaluate the code with C-c. When I do that, in my R session > buffer, I get to see several + + + until the final value is obtained, > and then the final value is shown, and inserted in my Org buffer. > > I was wondering if there is an option somewhere that will allow me to > instead see how each line in my R source code is evaluated. That is, > the R session buffer should show each line being evaluated, and then > show the final value as usual. Look at: http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html Use ESS to step through evaluation line-by-line Use C-c ' to visit the edit buffer for your code block Use ess-eval-line-and-step to evaluate each line in turn ess-eval-line-and-step is usually bound to C-c C-n I guess that is possible to use the same R session by configuring the session arguments and/or the ESS settings but I have not done it yet. If you do not have ESS you can try a more lightweight solution with isend-mode. Best, Daniele
Re: [O] problems with INCLUDE, noweb and tangle
Hello Sebastien, Sebastien Vauban writes: >> Thanks for the clarification. I did not noticed that before. I guess >> that there is no plan to get this working for the general case, so the >> only viable option is using one big .org file. > > Or use the Library of Babel, if the code you wanna tangle gets > eventually used in many different files? Thanks, I was not aware of this option. But it seems that the blocks are statically added to the variable org-babel-library-of-babel, so when I change the included files the changes does not propagate to the library of babel automatically. I also prefer a file based solution rather than a global one. Best, Daniele
Re: [O] problems with INCLUDE, noweb and tangle
Hello Nicolas, Nicolas Goaziou writes: > Hello, > > Daniele Pizzolli writes: > >> The noweb reference in the included file is not present in tangle (and >> sometimes also is not present within the results in the buffer). > > File inclusion, through INCLUDE keywords, is an export-only feature. Thanks for the clarification. I did not noticed that before. I guess that there is no plan to get this working for the general case, so the only viable option is using one big .org file. Best, Daniele
Re: [O] org the program vs. org the format
Hello Thomas, Thomas Koch writes: > Hi, > > there's a discussion on emacs-devel[1] about replacing texinfo as the > documentation format and org is mentioned. RMS correctly mentions that org- > mode is not a format but a program. > > This was also my problem when I thought about using org-mode at work in my > team. Since I'm the only emacs user we decided to use asciidoc which is a > format that can be edited and processed with different programs. > > So org-mode is a bit like PHP which also doesn't (didn't) have a > specification > but the implementation is the specification. > > Would it be possible to change the format of org-mode to be a superset of > e.g. > asciidoc or markdown but keep the features? Sorry for not answering directly but I am not enough knowledgeable. I like to point out that there is an ongoing attempt to specify the org syntax[1], and that there are translators[2] and tools[3] that can work with org source files. My personal workaround (but I am not sure it can scale for a community) is to have emacs and all the org dependencies packaged in a lightweight virtual machine. A set of script take care to send the org files to the vm and retrieve the results. Unfortunately my approach is quite rough, and I am not aware of any recent attempt to offer org-mode as a service[4]. If you have some degree of control of your build/continuous integration server I guess this is a viable solution. My use case is to have a clean environment where build a reproducible doc using babel, IMHO not so farm from using org for creating documentation. Like you I also have problem in sharing the result and the work, because of the high step for newcomers that do know little about emacs, command line and scripting. I think that we have some good examples for solving this, see for example the ipython notebook[5] and rmarkdown[6], both projects month after month gain more and more adoption. The great power of org is still winning for me, but I keep an eye on other approaches. Best, Daniele [1] http://lists.gnu.org/archive/html/emacs-orgmode/2014-09/msg00599.html [2] http://orgmode.org/worg/org-translators.html [3] http://orgmode.org/worg/org-tools/index.html [4] http://lists.gnu.org/archive/html/emacs-orgmode/2012-03/msg01097.html [5] http://ipython.org/notebook.html [6] http://rmarkdown.rstudio.com/
[O] problems with INCLUDE, noweb and tangle
Hello all, The noweb reference in the included file is not present in tangle (and sometimes also is not present within the results in the buffer). I am using: Org-mode version 8.3beta release_8.3beta-625-g8985b3 Please see the attached ECM with my comments (look for BUG). Let me know if you want to have a look to the generated files. You need ledger, but I guess this is a more general problem. Thanks in advance, Daniele #+EXPORT_EXCLUDE_TAGS: noexport * Org Setup :noexport: #+NAME: loadledger #+BEGIN_SRC emacs-lisp :results none (org-babel-do-load-languages 'org-babel-load-languages '((ledger . t) )) #+END_SRC * Financial Summaries ** Inline Opening :noexport: #+NAME: opening-inline #+BEGIN_SRC ledger :noweb yes :results output silent :exports none 2015-01-01 * Opening Assets:bank:savings:inline 1.00 € Equity:Opening Balances #+END_SRC ** Included Opening :noexport: #+INCLUDE: "./included.org" ** An overall balance summary #+name: balance #+BEGIN_SRC ledger :noweb yes :exports results :cmdline bal :results output <> <> #+END_SRC #+RESULTS: balance : 1.00 € Assets:bank:savings:inline : -1.00 € Equity:Opening Balances : :0 ** An overall balance summary with not working tangle In this section the result in the export are correct, but the tangled files contains only the =opening-inline= ref. BUG? #+name: tangled #+BEGIN_SRC ledger :noweb yes :tangle ledger-buggy1.dat :results output :exports results <> <> #+END_SRC #+RESULTS: tangled : 1.00 € Assets:bank:savings:inline : -1.00 € Equity:Opening Balances : :0 ** All the raw data In this section the result: - inline in the document =C-c C-c= are incorrect BUG? - in the tangled files contain only the =opening-inline= ref. BUG? - but in the exported file are correct #+name: tangled-buggy #+BEGIN_SRC ledger :noweb yes :tangle ledger-buggy2.dat :results output :exports results :cmdline print <> <> #+END_SRC #+RESULTS: tangled-buggy : 2015/01/01 * Opening : Assets:bank:savings:inline1.00 € : Equity:Opening Balances * Openings #+NAME: opening-included #+BEGIN_SRC ledger :noweb yes :results output silent :exports none 2015-01-01 * Opening Assets:bank:savings:included -1.00 € Equity:Opening Balances #+END_SRC
Re: [O] [PATCH] inline src block results can be removed
On 2014-11-24 12:12, Daniele Pizzolli wrote:
On 2014-11-24 11:18, Andreas Leha wrote:
Hi Daniele,
I think your wishlist is somewhere further down the road. I usually
implement some of your points in the src_language. I see that it
would
be nice if org supported these use cases, but I would see them as part
of the LOB or maybe in some package in contrib rather than in core
org/babel.
For that, I'd argue removable inline results that can be exported
without special formatting would be all that is needed to support your
wishlist.
Hi Andreas,
sure, I think I will start getting the string I needed from
src_language. But in some language is really hard to get facilities
for text manipulation while the output as table generally supported.
And I also think that the fine grained control of the layout of the
inline sentence pertains to the org layer.
Hi Andreas,
Yesterday I forgot to mention another reason because I think that the
formatting of the results pertains to the org layer and not to the
original language.
It's about proper boundaries and untrusted or limited trust of the
babel code. By default I wish to run untrusted code and display in a
safely manner the result. This is already possible by remote code
evaluation (but I not really checked if the output is always safely
escaped before the insertion in the org buffer).
Using the source language for outputting org-code is a viable
workaround for my needs but in the long run I will prefer to not
include some potential harmful generated org code.
I double checked about the output escaping right now. I guessed that
the output in the raw mode was safely escaped. But it really seems
the opposite: [[info:org#Results]]. However it seems that the RESULTS
code are not subsequently evaluated even with:
#+BEGIN_SRC elisp
(org-babel-do-load-languages
'org-babel-load-languages
'((sh . t)))
(setq org-export-babel-evaluate t)
#+END_SRC
Example:
#+NAME: is-this-safe-or-not
#+BEGIN_SRC sh :result output raw
printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 &&
echo true; echo false}'
#+END_SRC
# TODO: the pipe causes a bug...
#+RESULTS: is-this-safe-or-not
: Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo
true; echo false}
So now I am more confused than before... Has anybody a proof or a
counterexample that is (im)possible to run safely untrusted code on
(untrusted) remote host and still have the local buffer trusted?
By the way I really wanted to write:
#+NAME: problem-with-pipes...
#+BEGIN_SRC sh :result output raw
printf 'Is nested code generation always safe? src_sh{rm -Rf /tmp/123 &&
echo true || echo false}'
#+END_SRC
#+RESULTS: problem-with-pipes...
| Is nested code generation always safe? src_sh{rm -Rf /tmp/123 && echo
true | | echo false} |
I guess that something is wrong here:
Org-mode version 8.3beta (release_8.3beta-485-gf70439 @
/home/user/.emacs.d/el-get/org-mode/lisp/)
Maybe we need a new result format for safe output or am I missing
something?
Thanks in advance,
Daniele
Re: [O] [PATCH] inline src block results can be removed
On 2014-11-24 11:18, Andreas Leha wrote: Hi Daniele, I think your wishlist is somewhere further down the road. I usually implement some of your points in the src_language. I see that it would be nice if org supported these use cases, but I would see them as part of the LOB or maybe in some package in contrib rather than in core org/babel. For that, I'd argue removable inline results that can be exported without special formatting would be all that is needed to support your wishlist. Hi Andreas, sure, I think I will start getting the string I needed from src_language. But in some language is really hard to get facilities for text manipulation while the output as table generally supported. And I also think that the fine grained control of the layout of the inline sentence pertains to the org layer. A few inline comments below. Thanks again, they are really a nice help to start with! Best, Daniele
Re: [O] [PATCH] inline src block results can be removed
On 2014-11-17 00:23, Nicolas Goaziou wrote:
"Charles C. Berry" writes:
For now, I'd be willing to make patches that will allow removal of the
inline src block results that do *not* involve these header args:
[]
IMO, we're too much focused on the implementation details. We ought to
agree on what should be done first. For example, considering
`org-babel-insert-result' and its RESULT-PARAMS argument, I think the
following makes sense:
| Param | Example output|
|-+---|
| default | {{{results(42)}}} |
| file| {{{results(file:something.pdf)}}} |
| list| |
| raw | 42|
| drawer | |
| org | {{{results(src_org{...})}}} |
| html| {{{results(@@html:...@@)}}} |
| latex | {{{results(@@latex:...@@)}}} |
| code| {{{results(src_xxx{...})}}} |
Basically, it should be possible to remove any kind of result using
"results" macro, with the exception of "raw". "list" and "drawer" can
be ignored since there is no inline equivalent.
[]
There's no rush, however. Non-removable results from inline source
blocks have been there for a long time.
Hello all,
I jump into this conversation because in the next months I will try to
write a supplementary information annex using org-mode with Gnu R, so
my idea on what should be done follows...
I guess I will start my project using those patches. Thanks!
A brief review on how how results are presented (or usually
anticipated) inline led me to the following wish list:
* provide some facilities to keep track of the 'unit of measurement'
Few numbers are pure numbers. There is a little value added to the
correctness of the work as a whole if I get the correct number from
babel but I have hard coded the wrong unit of measure in the text.
Please follow the examples.
# Load used languages
#+BEGIN_SRC emacs-lisp
(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . nil)
(octave . t)
(R . t)))
#+END_SRC
Ideally, I think that reasonable solution would take table like the
following:
#+TBLNAME:speed-1
| speed | speed_unit |
|---+|
|12 | km/s |
and output by default or through an easy to call syntax:
#+BEGIN_EXAMPLE
12 km/s
#+END_EXAMPLE
I am not aware of any facilities provided by languages like R or
octave to keep track of the unit of measure, If you have some please
share.
A more space wise representation, that add another layer of
indirection would be to have a look-up table like the following:
#+TBLNAME:speed-1-units-lookup
| name | unit |
|+--|
| speed | km/s |
| length | km |
| time | s|
But I am not sure that it's worth it, at least for those that are
working with small data sets.
* support for inline rendering of tables
The most complex inline output I think I will need at some point
follows:
#+TBLNAME:data-set-1
#+NAME:data-set-1
| position | item1 | author1 | item2 | author2 | correlation |
|--+---+-+---+-+-|
|1 | i1| a1 | j1| b1 | c1 |
|2 | i2| a2 | j2| b2 | c2 |
|3 | i3| a3 | j3| b3 | c3 |
#+NAME: block-1
#+BEGIN_SRC R :session :colnames yes :exports none :var
data_set_1=data-set-1
# Just to show that we use R
data_set_2 <- data_set_1
#+END_SRC
#+RESULTS: block-1
| position | item1 | author1 | item2 | author2 | correlation |
|--+---+-+---+-+-|
|1 | i1| a1 | j1| b1 | c1 |
|2 | i2| a2 | j2| b2 | c2 |
|3 | i3| a3 | j3| b3 | c3 |
And I really like to be easily rendered as an inline string through
some formatting specs e.g.:
#+BEGIN_EXAMPLE
#+PROPERTY: header-args: R :fmt '(%(position)i) “%(item1)s” by
/%(author1)s/ correlate to “%(item2)s” by /%(author2)s/ with a
correlation coefficient of %(correlation).2f'
#+PROPERTY: header-args: R :rowsep (', ', ' and ')
The preliminary results show that: src_R[:session :results
replace]{data_set_2}.
#+END_EXAMPLE
Will be rendered as:
#+BEGIN_org
The preliminary results show that:
(1) “i1” by /a1/ correlate to “j1” by /b1/ with a correlation
coefficient of c1,
(2) “i2” by /a2/ correlate to “j2” by /b2/ with a correlation
coefficient of c2 and
(3) “i3” by /a3/ correlate to “j3” by /b3/ with a correlation
coefficient of c3.
#+END_org
For languages that does not support tables with headers we can stick
with the positional formatting:
#+NAME: block-2
#+BEGIN_SRC octave :session :colnames yes :exports none :var
data_set_1=data-set-1
ans = data_set_1;
#+END_SRC
# TODO: figure out why this does not work
#+RESULTS: block-2
: iii123aaa123jjj123bbb123ccc123
#+BEGIN_EXAMPLE
#+PROPERTY: header-args: octave :f
Re: [O] [FR] fill caption
On 06/15/2014 12:34 AM, Aaron Ecay wrote: Hi Daniele, 2014ko ekainak 14an, Daniele Pizzolli-ek idatzi zuen: Hello @ll, I noticed that multi line caption works as expected, but there is no way to fill it (at least to my knowledge). [] I have the following function in my org-mode-hook: Hello Aaron, Nice, since I do not use short caption, this could be really a viable solution. How I am supposed to set it up? I added it as: (add-hook 'org-mode-hook (lambda () (awe-org-setup-fill-hook))) When pressing M-q it does nothing on #+caption: lines. If I enable the debug (fill-adapt-debug) I can see (org-message) in the status bar and "#+caption: " becomes highlighted. But again M-q does nothing. I am using: org 8.2.7. If you use ispell’s facility for adding to LocalWords (pressing A (i.e. shift+a) at the spelling correction prompt, or “Accept (buffer)” in the context menu), it will handle breaking the LocalWords lines for you. Yes, but do not re-fill the previous lines (eg: if you change fill-column). But that is a minor annoyance, let’s drop it now. Hope this is useful, Sure! Thanks, Daniele
Re: [O] [FR] fill caption
On 06/14/2014 08:04 PM, Nicolas Goaziou wrote: Hello, Daniele Pizzolli writes: I noticed that multi line caption works as expected, but there is no way to fill it (at least to my knowledge). [] This was requested before. In a nutshell, this can be done, but there are some caveats (see http://permalink.gmane.org/gmane.emacs.orgmode/82083). Thanks Nicolas, I missed it, I double checked only: http://orgmode.org/worg/org-issues.html Next time will do a search on the mailing list before submitting a feature request. Best, Daniele
[O] [FR] fill caption
Hello @ll, I noticed that multi line caption works as expected, but there is no way to fill it (at least to my knowledge). I added a test case that should speak by itself. I do not know a lot of elisp, but if you have some pointer I could try to implement it by myself. Maybe this could be extended to handle also OPTIONS and LocalWords and others. Thanks in advance, Daniele diff --git a/testing/lisp/test-org.el b/testing/lisp/test-org.el index 39db5bf..7ebac61 100644 --- a/testing/lisp/test-org.el +++ b/testing/lisp/test-org.el @@ -362,6 +362,19 @@ (end-of-line) (org-auto-fill-function) (buffer-string)) + ;; Correctly fill the caption. + (should + (equal "#+CAPTION: this is a very very\n#+CAPTION: long caption" + (org-test-with-temp-text "#+CAPTION: this is a very very long caption" + (let ((fill-column 30)) + (org-fill-paragraph) + (buffer-string) + (should + (equal "#+CAPTION: this is a very short caption" + (org-test-with-temp-text #+CAPTION: this is a very \n#+CAPTION: short caption" + (let ((fill-column 80)) + (org-fill-paragraph) + (buffer-string)
[O] buggy subscripts and superscripts escape with latex export
Hello all,
my original problem was how to get "a_b" exported literal using the
latex exporter. I explored a bit the sub/superscript options and I
think that there are some buggy behaviors.
The following code:
* test
- subscript a_b
- subscript escaped a\_b
- superscript a^b
- superscript escaped a\^b
Will produce with Org-mode version 7.9.4:
\begin{itemize}
\item subscript a$_b$
\item subscript escaped a\_b
\item superscript a$^b$
\item superscript escaped a\^b
\end{itemize}
And will produce with Org-mode version 8.2.1 (release_8.2.1-75-g45d81d
...)
\begin{itemize}
\item subscript a$_{\text{b}}$
\item subscript escaped a$\backslash$$_{\text{b}}$
\item superscript a$^{\text{b}}$
\item superscript escaped a$\backslash$$^{\text{b}}$
\end{itemize}
According to the manual
http://orgmode.org/manual/Subscripts-and-superscripts.html#Subscripts-and-superscripts
- The subscript escape is working correctly in 7.9.4
- The subscript escape is not working correctly in 8.2.1
- The superscript escape is not working correctly in 8.2.1.
- I do think that superscript escape is not working correctly in
7.9.4. It produces something like a LATIN SMALL LETTER B WITH
CIRCUMFLEX instead of the expected b with "^" before.
I did not have any success following the suggestion in the manual, eg:
(setq org-use-sub-superscripts "{}")
But at the end writing:
#+OPTIONS: ^:{}
and a plain "a_b" solved the issue for me.
Regards,
Daniele
Re: [O] Bug: dates in heading break beamer export
On 10/03/2013 03:30 PM, Nicolas Goaziou wrote: The following patch should protect some fragile commands in a section-like structure. It is Beamer-only since general LaTeX back-end doesn't seem to encounter these problems. Does it fix the problem? Hello Nicolas, yes, the problem is fixed both for dates and footnotes in sections, and should be fixed for any of: bold footnote-reference italic strike-through timestamp underline if I understand it correctly. Nice! I hope you plan to merge it. Thanks you, Daniele
Re: [O] Bug: dates in heading break beamer export
On 10/02/2013 05:55 PM, Nicolas Goaziou wrote: Daniele Pizzolli writes: Yes, I think is fair to drop the markup. OK. I would also think that this is safe default when nested markup is bad. Do you have an exhaustive list of such cases? No, not really but I try to report them as soon I found them. I do want to replace latex entirely with org, so I will use it extensively in the near future. Maybe the exporter can emit a notice/warning. That it dropped the markup? Yes, I do not know if there is already a standard in reporting back but I would go for something like "Latex-exporter: Warning: dropped code markup at line XX of originalorgfile.org because it is not supported by this exporter. More info at ..." or even a shorter one can be fine to me. Yes, sorry, I mixed two not-so-related problem. The beamer exporter do not work with this code: #+OPTIONS: H:3 * title test[fn:1] ** section *** subsection [fn:1] text Of course, that's a similar problem: footnotes are not allowed in headlines. Though, in this case, it isn't possible to drop the markup. What LaTeX code do you suggest? Mmm, I think you are asking to the wrong person. I do not know enough about latex and its error reporting capabilities... I would appreciate if the exporter does not break and/or a notification to the user of the problem in and understandable language, even for newcomers. I know when latex do not know how to resolve some references put some question marks... but I do not really know if this is the case to follow this convention. Regards, Daniele
Re: [O] Bug: dates in heading break beamer export
On 10/02/2013 03:45 PM, Nicolas Goaziou wrote: Hello, Daniele Pizzolli writes: In fact I use org-mode primarily to stay away from *tex nuisances... and I think that I am not the only one. I know enough latex to find a workaround myself (not enough to offer a general reliable solution) but I do not think that this will be a pleasant experience for a newcomer or to somebody that choose org-mode for the latex export capability. Fair enough. What, exactly, do you suggest as generated LaTeX code? Thanks Nicolas for following my arguments. IIUC, you want to drop any markup for timestamps when located in a headline, ignoring `org-latex-active-timestamp-format' and al. Am I missing something else? Yes, I think is fair to drop the markup. I would also think that this is safe default when nested markup is bad. Maybe the exporter can emit a notice/warning. BTW, the =verbatim=[fn:1] case is unrelated to export. See `org-emphasis-regexp-components'. Yes, sorry, I mixed two not-so-related problem. The beamer exporter do not work with this code: #+OPTIONS: H:3 * title test[fn:1] ** section *** subsection [fn:1] text The output is: org-latex-compile: PDF file ./beamer-bug-footnote.pdf wasn't produced: [undefined control sequence] Runaway argument The =verbatim=[fn:1] problem was discovered trying to find a workaround for the footnotes in the headers... Oh, in fact searching emphasis + footnote lead to some results. The question hit this list periodically... so maybe it’s worth documenting it better. I will try found a general answer and propose a patch for the docs. It seems that I am going to drop latex nuisances to go into elisp ones ;-) Thanks again, Daniele
Re: [O] Bug: code and footnotes (was Bug: dates in heading break beamer export)
On 09/30/2013 07:05 PM, Marcin Borkowski wrote: [] - =string=[footnote] Just curious: what's the problem with =string=[footnote]? Hello Marcin, This line do no really cause errors on latex but do no export the code and/or the footnote and leaves the equals in the output. Here are some cases: #+OPTIONS: H:3 * title ** section *** subsection test[fn:1] good: text, footnote, no equals =test=[fn:2] bad: no code(bad), footnote, equals(bad) =test[fn:3]= bad: code, no footnote(bad), equals(bad) =test=\[fn:4] bad: code, footnote, no equals, slash(bad?) =test=[fn:5] bad: no code(bad), footnote, equals (bad) (please note that there is a zero with whitespace before “[”) [fn:1] t1 [fn:2] t2 [fn:3] t3 [fn:4] t4 [fn:5] t5 * title 2 Best, Daniele
Re: [O] Bug: dates in heading break beamer export
On 09/30/2013 06:02 PM, Daniele Pizzolli wrote: But org-mode allow this! I think that if something is allowed in org-mode syntax but not by the underlining tools used for export, the exporter should take care to find a suitable workaround. Hello all, I see all your interesting points on the discussion... I just want to explain that my statement is my naïve interpretation of: You can use intuitive markup then have it converted to HTML, LATEX, ODT – and much more[fn:1]. I can understand that the markup can end in very complex cases, but I hope that you agree with me that with this advertised feature an extra care should be put in ensuring that every markup can be exported without crashing some tool in the chain. The latex and html exporters (the one I use most) do already a wonderful job, but some important case are missing. Since I found a healthy and friendly community I was thinking that was worth reporting them. In fact I use org-mode primarily to stay away from *tex nuisances... and I think that I am not the only one. I know enough latex to find a workaround myself (not enough to offer a general reliable solution) but I do not think that this will be a pleasant experience for a newcomer or to somebody that choose org-mode for the latex export capability. Regards, Daniele [fn:1] http://orgmode.org/features.html#sec-7
Re: [O] list items not treated as such.
On 09/29/2013 09:05 PM, Paul Rudin wrote: Daniele Pizzolli writes: [] Yeah, I have that in my init.el, it's not a general problem with alphabetic labels, it's only in some contexts that problem happens. hitting alt-enter at the end of item a) works just fine for example - I get the b) label inserted correctly for example. Hello Paul, With my setup I experience the correct auto-fill. Maybe you want to try a more recent version of org-mode? Which one are you using now? Regards, Daniele
Re: [O] Bug: dates in heading break beamer export
On 09/29/2013 05:27 PM, Marcin Borkowski wrote:
Dnia 2013-09-29, o godz. 16:53:14
Nicolas Goaziou:
[]
It's a LaTeX Beamer problem: it doesn't like
\section{title \textit{[2013-09-29 Sun]}}
produced by Org, although regular LaTeX accepts it.
Do you know about a workaround for this?
Not really.
This is really a workaround: put a \protect before \textit.
Or why not drop \textit?
In general, putting formatting commands in \section title etc., even if
not erroneous, is considered a bad practice.
But org-mode allow this!
I think that if something is allowed in org-mode syntax but not by the
underlining tools used for export, the exporter should take care to find
a suitable workaround.
I just found that the same problem (work in latex, does not work in
beamer) exists for footnotes in header!
A feature request would be to have some checks on org files a la
flymake, at least for common potential sources of problems that
usually break the export like:
- missing two empty lines after footnotes
- missing empty line after RESULTS:
- =string=[footnote]
Maybe something already exists and I am simply not aware.
Regards,
Daniele
Re: [O] list items not treated as such.
On 09/29/2013 08:40 PM, Paul Rudin wrote: Example: 1. Some text that extends over more than one line, I'm not sure if the exact length is relevant. a) stuff; and then b) this item will not be recognised as a list item, which can be a bit of a pain, so if you're typing with auto-fill on it will be formatted like this, but really the second line should align underneath the text of the start of the item. Is this working as intended? It seems wrong to me - if I type item b) above it surely should fill properly? Hello Paul, Be sure to have this setting: #+BEGIN_SRC emacs-lisp :results none (setq org-list-allow-alphabetical t) #+END_SRC Regards, Daniele
Re: [O] [bug] how to specify the format for clock table summaries and bug in formula calculations
On 09/29/2013 02:33 PM, Eric S Fraga wrote: Hello, Hello Eric, I am clocking a number of tasks and need a summary. The functionality provided by the org-clock table is ideal for my use case. However, the total time summaries use numbers of days when the number of hours exceeds 24. Although this is fine most of the time, I would like to have total hours instead. Is this possible? I found this snippet in the past: #+BEGIN_SRC elisp :results silent (setq org-time-clocksum-format '(:hours "%d" :require-hours t :minutes ":%02d" :require-minutes t)) #+END_SRC [] More importantly, the ":formula %" option does not work as soon as days appear in the summaries! With the suggested format it seems to be correct: #+BEGIN: clocktable :maxlevel 2 :scope file :formula % #+CAPTION: Clock summary at [2013-09-29 Sun 15:22] | Headline | Time| | % | |--+-+---+---| | *Total time* | *50:03* | | 100.0 | |--+-+---+---| | clocking | 50:03 | | 100.0 | | \__ task A | | 12:02 | 24.0 | | \__ task B | | 12:51 | 25.7 | | \__ task C | | 25:10 | 50.3 | #+TBLFM: $4='(org-clock-time% @2$2 $2..$3);%.1f #+END: clocktable Regards, Daniele
[O] Bug: dates in heading break beamer export
Hello @all, Dates in org-format in heading break the beamer export: Minimal case: #+OPTIONS: H:3 * title [2013-09-29 Sun] ** section *** frame text Result for beamer export: org-latex-compile: PDF file ./beamer-bug-date.pdf wasn't produced: [undefined control sequence] Runaway argument The same error for: #+OPTIONS: H:3 * title <2013-09-29 Sun> ** section *** frame text This works: #+OPTIONS: H:3 * title (2013-09-29 Sun) ** section *** frame text The export in latex for the same snippets works in all cases in version: Org-mode version 8.2 (release_8.2-6-gd08917 ...) Regards, Daniele
Re: [O] example filter for code blocks?
John Kitchin wrote:
Hi everyone,
I have an idea for putting links in a pdf that would open python code
blocks in an editor. To do that, I need to modify what happens when an
org-file is published to latex.
Hello John,
Few days ago, I did some research on the general problem:
- not python specific (code agnostic)
- not latex specific (export back-end agnostic)
Unfortunately I ended up only for specific parts, but hope that can be
useful starting points.
I think that the ability to attach code blocks in a easy and general
way can be a nice improvement.
Essentially I want it to do exactly what it already does in terms of
running pygments, and making nicely formatted and syntax highlighted
code blocks and output.
After that though, I want to tangle the code block to a file in a
directory, and insert a new link after the rendered code block. I
would prefer not to have to put :tangle headings in each code block
because there are many (e.g. hundreds) of them in course notes.
sufficient if they were just sequentially numbered as dir/1.py,
dir/2.py, etc... and it is fine if these get overwritten on each
export.
If can live with a different file per section instead of per code
block you can group the common setting, eg:
:PROPERTIES:
:header-args: octave :session *octave-sess* :exports both :results output
:tangle lab1-ex1.m
:END:
the link that would go after the code block in the latex export would
be something like: \LaunchPython{dir/1.py}{Open code}
Then clicking on it would open dir/1.py in whatever editor your
system is configured for. \LaunchPython is a newcommand I have
defined that works already.
My hack with limited use to latex and html (and probably will not copy
the tangled file with html publish) is:
#+LATEX_HEADER: \usepackage{attachfile}
#+MACRO: embed-matlab @@latex:\textattachfile[mimetype=text/x-matlab,color=0 0 0.5]{$1}{$1}@@
@@html:$1@@
#+NAME: code:2
#+BEGIN_SRC octave
x = 1:10
#+END_SRC
Snippets of octave source code for this exercise
{{{embed-matlab(lab1-ex1.m)}}}
It seems like the new export engine should make this easy to do, but
I am not sure where to start. Could anyone point me to a starting
place? Thanks!
I only have limited lisp knowledge, but I am interested as well in
pointers for a general solution.
Regards,
Daniele
Re: [O] Tentative patch to keep org-babel-results-keyword when calling org-babel-remove-result
On 09/21/2013 12:30 AM, Eric Schulte wrote: Hi Daniele, Thanks for catching this very large edge case which I completely ignored. I've just pushed up a fix. Hi Eric, Thanks to you for fixing it. It never ceases to amaze me how many clever thighs org-mode can do! Regards, Daniele Pizzolli
Re: [O] Tentative patch to keep org-babel-results-keyword when calling org-babel-remove-result
On 09/20/2013 11:13 PM, Eric Schulte wrote: Hi Daniele, Thanks for the suggestion and the accompanying patch. I've just applied a modified version of your patch (included below). Please let me know if this is insufficient for your needs. Hello Eric, Wonderful! Your patch is perfect for my use case. Thanks for the quick improvement! I just re-discovered the amazing feature of "named source blocks". that unfortunately trigger a corner case: #+NAME: fig1 #+BEGIN_SRC... #+END_SRC Some text #+RESULTS: fig1 ** Other section After running: (org-babel-map-src-blocks nil (org-babel-remove-result nil t)) Will result in: #+NAME: fig1 #+BEGIN_SRC... #+END_SRC Some text #+RESULTS: f ** Other section I tried to look at the code, but the level of indirection you added makes me feel lost. I would be happy to help in testing, even with more use cases if needed. I just found that the section “Writing tests with minimal Emacs-lisp knowledge” at http://orgmode.org/worg/org-tests/index.html#sec-3 is not yet complete but I can have a look at the source code and follow your advises or examples. Thanks again, Daniele Pizzolli
[O] Tentative patch to keep org-babel-results-keyword when calling org-babel-remove-result
Hello @ll, this is my fist post on the list. Thanks to everybody for posting interesting things and keeping org-mode improving! I am seeking help because of my limited elisp knowledge. This is my incomplete patch to extend org-babel-remove-result to keep the org-babel-results-keyword when removing the results. I need to keep the org-babel-results-keyword because I want to commit to my dvcs a clean file and easily evaluate the results at any time later. Unfortunately running org-babel-remove-result on a snippet like the following: #+BEGIN_SRC octave :results value file % at the end produce an image #+END_SRC #+ATTR_LATEX: :width 3cm #+RESULTS: [[file:image_01.png]] Will output: #+BEGIN_SRC octave :results value file % at the end produce an image #+END_SRC #+ATTR_LATEX: :width 3cm And a run of org-babel-execute-buffer will produce: #+BEGIN_SRC octave :results value file % at the end produce an image #+END_SRC #+RESULTS: [[file:image_01.png]] #+ATTR_LATEX: :width 3cm changing the position of the LaTeX specific attribute #+ATTR_LATEX: in way that it becomes useless. The patch add an optional argument to org-babel-remove-result but relies to an hard-coded value of the length of the default org-babel-results-keyword plus syntax elements: "#+RESULTS:". Instead of calculating lengths I think that is better to move to next line. I also skipped a deletion of the last char assuming that is always a new line. Is this assumption correct? If we delete the last line we can end with: #+RESULTS: ** some other section That will cause problem in the next evaluation. I will appreciate your suggestions to improve the patch myself. It would be great also if anybody can implement it properly and get it merged. Thanks in advance, Daniele Pizzolli diff --git a/lisp/ob-core.el b/lisp/ob-core.el index cc6b7a9..7517ebf 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -2159,15 +2159,18 @@ code the results are extracted in the syntax of the source (set-marker visible-beg nil) (set-marker visible-end nil)) -(defun org-babel-remove-result (&optional info) - "Remove the result of the current source block." +(defun org-babel-remove-result (&optional info keep-keyword) + "Remove the result of the current source block. Optionally +keep the result keyword." (interactive) (let ((location (org-babel-where-is-src-block-result nil info)) start) (when location - (setq start (- location 1)) + (setq start (if keep-keyword (+ location 10) (- location 1))) (save-excursion (goto-char location) (forward-line 1) -(delete-region start (org-babel-result-end)) +(delete-region + start + (if keep-keyword (- (org-babel-result-end) 1) (org-babel-result-end)))
