Re: [O] ob-shell and remote shells
Hello, "numbch...@gmail.com" writes: > Off the topic, I'm curious what is the `:session` in `ob-shell` ? it basically means that state is preserved for code blocks that run in the same session (as long as the interpreter is running). Or in other words, imagine two code blocks: the first sets a variable, the second prints the variable. Without sessions the code blocks run in different shell instances and the second block doesn't 'see' the variable set by the first code block. But if both run in the same session, the second code block 'sees' the state left by the first code block. Regard hmw
Re: [O] ob-shell and remote shells
Off the topic, I'm curious what is the `:session` in `ob-shell` ? [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Tue, Nov 28, 2017 at 4:45 PM, Michael Welle wrote: > Hello, > > I want to execute shell blocks like follows: > > #+BEGIN_SRC shell :session n42 :dir /127.0.0.1: :shebang "#!/bin/bash" > echo los > echo $SHELL > echo $BASH > echo ready > #+end_src > > The trouble is that the shebang property doesn't work in this case. The > script is executed with the login shell of the user and fails because of > syntax errors (for instance, if bashisms are used in the script). > > With my minimal and dangerous knowledge about Org's source code ;), I > think the following might work (from ob-shell.el): > > (defun org-babel-sh-initiate-session (&optional session _params) > "Initiate a session named SESSION according to PARAMS." > (when (and session (not (string= session "none"))) > (save-window-excursion > (or (org-babel-comint-buffer-livep session) > (progn > (let ((explicit-shell-file-name (xxx))) > (shell session)) > ;; Needed for Emacs 23 since the marker is initially > ;; undefined and the filter functions try to use it without > ;; checking. > (set-marker comint-last-output-start (point)) > (get-buffer (current-buffer))) > > > Note the let form. Further tasks that have to be done is to add the > shebang key to _params, which I hope is available at all places where > o-b-s-i-s is evaluated. Further at (xxx) a regexp etc. is needed to > transform the shebang line to a shell path suitable for e-s-f-n. > > Any opinions, please? Depending on the opinions I will implement the > approach this week and see if it works as expected. > > Regards > hmw > >
[O] Custom agenda with tags-todo and shorthand todo specification ignored if hypen present in TODO state
Hi, I have the following in my custom block agenda to sort for work tags that are in progress: (tags-todo "@work+TODO=\"IN-PROGRESS\"" ((org-agenda-overriding-header "\nIn progress tasks\n-\n"))) (tags-todo "@work/IN-PROGRESS" ((org-agenda-overriding-header "\nIn progress tasks\n-\n"))) The first version correctly populates the in progress block entry, but the second does not. It seems that the issue may be related to the hypen in the shorthand version. I don't know if this is a bug or expected behaviour. Either way the first variant works fine so not a big problem. Cheers, Adrian
[O] bug#18617: bug#18617: 24.3; loading simple-wiki-mode breaks org-mode
# not an Emacs bug tags 18617 notabug close 18617 quit Kaushal Modi writes: > A quick look at the code shows that it pollutes the namespace with > undeclared and un-let-bound variables like "tag" (and there could be > more like that). > > If we investigate further, we might find a culprit like that that's > causing this problem. Looks like this is a bug in simple-wiki-mode, not in Emacs.
Re: [O] Results with #+begin_example/#+end_example don't get overwritten
On Tue, Nov 28, 2017 at 6:16 PM Nicolas Goaziou wrote: > > AFAICT, there is no place in the manual that explains what is the > RESULTS keyword OK, may be that's the first step :) and under what circumstances it could be useful to write > it manually. > No, I wasn't suggesting a use case where someone writes the #+RESULTS: contents manually. Here's what can happen though: A user could have this to begin with: = #+BEGIN_SRC emacs-lisp (message "Hello") #+END_SRC #+RESULTS: : Hello | some | thing | important | = Then for whatever reason, they choose to delete the RESULTS manually.. and the blank line after that too! = #+BEGIN_SRC emacs-lisp (message "Hello") #+END_SRC #+RESULTS: | some | thing | important | = Now C-c C-c in the src block will wipe out the user-entered table! = #+BEGIN_SRC emacs-lisp (message "Hello") #+END_SRC #+RESULTS: : Hello = That's why I proposed earlier to wrap the Org generated results in something like #+begin_results/#+end_results. That way, Org is always sure that what it's deleting/overwriting is not user-entered data. The current behavior is risky, or at least should somehow be documented. -- Kaushal Modi
Re: [O] Bizarre gnuplot file creation error
Hello, Eric S Fraga writes: > On Thursday, 16 Nov 2017 at 22:40, Nicolas Goaziou wrote: >> Hello, >> >> Eric S Fraga writes: >> >>> The proper solution would be to update ob-gnuplot to change the working >>> directory at every invocation of gnuplot to be the directory where the >>> org file is found. (gnuplot has a "cd" command for this purpose) >> >> Would you like to propose a patch for that? BTW should the new working >> directory be Org file's or :file, or even :dir? > > Nicolas, > > can you please advise on how to get the directory the originating org > file may lie in from within org-babel-expand-body:gnuplot? No idea. (and (buffer-file-name) (file-name-directory (buffer-file-name))) ? The originating Org file may not exist. Regards, -- Nicolas Goaziou
Re: [O] Results with #+begin_example/#+end_example don't get overwritten
Kaushal Modi writes: > Regarding the earlier point I made about data safety, should we mention in > the manual that a user must always leave a blank line after #+RESULTS, > especially if they have one of these following the #+RESULTS: keyword? > > (drawer example-block export-block fixed-width item plain-list src-block > table) AFAICT, there is no place in the manual that explains what is the RESULTS keyword and under what circumstances it could be useful to write it manually. Therefore, I think detailing the caveats of RESULTS manual insertion is a bit premature at this point. WDYT?
Re: [O] changed visibility when using org-goto-named-src-block
Hello, Eric S Fraga writes: > On Monday, 27 Nov 2017 at 17:48, Berry, Charles wrote: >> This happens when `org-babel-src-block-names' calls `org-next-block' >> calls `org-show-context'. > > Thanks. Was it always thus? It would be nice to have the visibility go > back to what it was before the command was invoked. I have made `org-babel-src-block-names' more neutral, since it is not interactive. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Results with #+begin_example/#+end_example don't get overwritten
On Tue, Nov 28, 2017 at 5:36 PM Nicolas Goaziou wrote: > Yes, I simply forgot to add the `example-block' type. Now fixed. Thank > you. > Thanks. Regarding the earlier point I made about data safety, should we mention in the manual that a user must always leave a blank line after #+RESULTS, especially if they have one of these following the #+RESULTS: keyword? (drawer example-block export-block fixed-width item plain-list src-block table) -- Kaushal Modi
Re: [O] Results with #+begin_example/#+end_example don't get overwritten
Hello, Kaushal Modi writes: > Or may be just do this: > > diff --git a/lisp/ob-core.el b/lisp/ob-core.el > index 00f0fe33ecf..f04392a96d2 100644 > --- a/lisp/ob-core.el > +++ b/lisp/ob-core.el > @@ -2465,7 +2465,7 @@ in the buffer." > (if (memq (org-element-type element) > ;; Possible results types. > '(drawer export-block fixed-width item plain-list src-block > - table)) > + example-block table)) Yes, I simply forgot to add the `example-block' type. Now fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Results with #+begin_example/#+end_example don't get overwritten
On Tue, Nov 28, 2017 at 4:58 PM Kaushal Modi wrote: > I think that this behavior is on a safe side and good, but there needs to > be a way for Org to figure out if the stuff following #+RESULTS is safe to > delete.. > > Can be probably have #+begin_results and #+end_results instead of > #+begin_example and #+end_example? And then process the > begin_results/end_results elements the same as example elements? > > That way, we can safely delete/overwrite the begin_results/end_results > blocks. > > In the above example, Org cannot know if that example block is babel > generated or user-typed. > > WDYT? > Or may be just do this: diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 00f0fe33ecf..f04392a96d2 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -2465,7 +2465,7 @@ in the buffer." (if (memq (org-element-type element) ;; Possible results types. '(drawer export-block fixed-width item plain-list src-block - table)) + example-block table)) (save-excursion (goto-char (min (point-max) ;for narrowed buffers (org-element-property :end element))) -- Kaushal Modi
[O] Results with #+begin_example/#+end_example don't get overwritten
Hello, This issue is at the opposite spectrum of the previous issue where the Org element after #+RESULTS got overwritten.. Here's a MWE: = #+TITLE: Results with #+begin_example/#+end_example do not get overwritten #+PROPERTY: header-args:python :exports both :results output #+BEGIN_SRC python print('a'.islower()) print('A'.islower()) print('abc'.islower()) print('Abc'.islower()) print('aBc'.islower()) print('012'.islower()) print('{}'.islower()) print('ABC'.islower()) print('À'.islower()) print('à'.islower()) #+END_SRC = With point on the src block, hit C-c C-c; you will get: = #+TITLE: Results with #+begin_example/#+end_example do not get overwritten #+PROPERTY: header-args:python :exports both :results output #+BEGIN_SRC python print('a'.islower()) print('A'.islower()) print('abc'.islower()) print('Abc'.islower()) print('aBc'.islower()) print('012'.islower()) print('{}'.islower()) print('ABC'.islower()) print('À'.islower()) print('à'.islower()) #+END_SRC #+RESULTS: #+begin_example True False True False False False False False False True #+end_example = But doing C-c C-c again will now give: = #+TITLE: Results with #+begin_example/#+end_example do not get overwritten #+PROPERTY: header-args:python :exports both :results output #+BEGIN_SRC python print('a'.islower()) print('A'.islower()) print('abc'.islower()) print('Abc'.islower()) print('aBc'.islower()) print('012'.islower()) print('{}'.islower()) print('ABC'.islower()) print('À'.islower()) print('à'.islower()) #+END_SRC #+RESULTS: #+begin_example True False True False False False False False False True #+end_example #+begin_example True False True False False False False False False True #+end_example = I think that this behavior is on a safe side and good, but there needs to be a way for Org to figure out if the stuff following #+RESULTS is safe to delete.. Can be probably have #+begin_results and #+end_results instead of #+begin_example and #+end_example? And then process the begin_results/end_results elements the same as example elements? That way, we can safely delete/overwrite the begin_results/end_results blocks. In the above example, Org cannot know if that example block is babel generated or user-typed. WDYT? -- Kaushal Modi
Re: [O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Hello, Ruy Exel writes: > With the new implementation, is it possible to insert a column to the > left of the first column? I assume this is done with M-S- followed with M-. Regards, -- Nicolas Goaziou
Re: [O] C++ code block not linked [SOLVED]
Thierry Banel writes: > On 28/11/2017 18:08, Roger Mason wrote: > > Hello, > > Roger Mason writes: > > It compiles fine: > > c++ -std=c++11 -I/usr/local/include -L/usr/local/lib -lginac > C-src-1053hn1.cpp > > Solved by setting: > > (setq org-babel-C++-compiler "c++") > > I don't recall having had to do this before. > > Phew! Very glad to have this working again. I'm not aware of any other > tool > that is as good as org-mode for literate programming and reproducible > research. A big thank you to those who created and maintain it. > > Cheers, > Roger > > Good to know it is solved. > You can customize this variable: > C-h v org-babel-C++-compiler > > In case someone else bump into a similar problem, the actual command launched > by Babel can be obtained > through the debugger: > M-x debug-on-entry RET org-babel-eval RET > evaluate the Babel block > The debugger shows a line like this one: > * org-babel-eval("g++ -o /tmp/babel-3110Zeg/C-bin-3110Fwh -std=c++11 ... > This works for many languages supported by Babel. > All very good info, but why did the OP not have a g++? Using a non-linux operating system? Using a non-GNU tool chain? Inquiring minds want to know... -- Nick
Re: [O] Deletion immediately after insertion should leave org-mode tables unaltered but it doesn't
Hi Nicolas, With the new implementation, is it possible to insert a column to the left of the first column? Best, Ruy On Tue, Nov 21, 2017 at 8:47 PM, Nicolas Goaziou wrote: > Hello, > > Ruy Exel writes: > >> This is indeed a good idea as it mimics the creation of a row in emacs >> text-mode with "C-o". > > This is now implemented. > > Regards, > > -- > Nicolas Goaziou0x80A93738
Re: [O] C++ code block not linked [SOLVED]
On 28/11/2017 18:08, Roger Mason wrote: Hello, Roger Mason writes: It compiles fine: c++ -std=c++11 -I/usr/local/include -L/usr/local/lib -lginac C-src-1053hn1.cpp Solved by setting: (setq org-babel-C++-compiler "c++") I don't recall having had to do this before. Phew! Very glad to have this working again. I'm not aware of any other tool that is as good as org-mode for literate programming and reproducible research. A big thank you to those who created and maintain it. Cheers, Roger Good to know it is solved. You can customize this variable: C-h v org-babel-C++-compiler In case someone else bump into a similar problem, the actual command launched by Babel can be obtained through the debugger: M-x debug-on-entry RET org-babel-eval RET evaluate the Babel block The debugger shows a line like this one: * org-babel-eval("g++ -o /tmp/babel-3110Zeg/C-bin-3110Fwh -std=c++11 ... This works for many languages supported by Babel.
Re: [O] changed visibility when using org-goto-named-src-block
> On Nov 27, 2017, at 11:54 PM, Eric S Fraga wrote: > > On Monday, 27 Nov 2017 at 17:48, Berry, Charles wrote: >> This happens when `org-babel-src-block-names' calls `org-next-block' >> calls `org-show-context'. > > Thanks. Was it always thus? No. In 8.0.7 (and probably later versions) org-babel-src-block-names did not use `org-next-block'. Agree that keeping visibility as close to original as possible is a good thing, but do not have time to play with it these days. Chuck
Re: [O] C++ code block not linked [SOLVED]
Hello, Roger Mason writes: > It compiles fine: > > c++ -std=c++11 -I/usr/local/include -L/usr/local/lib -lginac > C-src-1053hn1.cpp Solved by setting: (setq org-babel-C++-compiler "c++") I don't recall having had to do this before. Phew! Very glad to have this working again. I'm not aware of any other tool that is as good as org-mode for literate programming and reproducible research. A big thank you to those who created and maintain it. Cheers, Roger
Re: [O] Bug (not a): drawer alignment [9.1.2 (9.1.2-32-g271e58-elpaplus @ c:/USR/FJM/APP/.emacs.d/elpa/org-plus-contrib-20171106/)]
Hello, "Francis J. Monari, Esquire" writes: > I sent an email with a question regarding the alignment of drawers with > the immediately preceding headline. > > The "problem" is still occurring, however, the "problem" is resolved > after I run the org-lint utility on the file. Note that running > org-lint fixed the "problem" not only with the file that was "linted", > but with all the org mode files (which also showed the "problem"). > > I am writing to withdraw my question (my org mode setup is working), but > also to mention that there appears to be some side-effect to running > org-lint. This side-effect may prove be a latent bug that would affect > future updates/revisions to org mode. Again, could you provide a demonstration of the issue? This is very mysterious. BTW, I don't think there is any side-effect in Org Lint. Regards, -- Nicolas Goaziou
[O] Bug (not a): drawer alignment [9.1.2 (9.1.2-32-g271e58-elpaplus @ c:/USR/FJM/APP/.emacs.d/elpa/org-plus-contrib-20171106/)]
All, I sent an email with a question regarding the alignment of drawers with the immediately preceding headline. The "problem" is still occurring, however, the "problem" is resolved after I run the org-lint utility on the file. Note that running org-lint fixed the "problem" not only with the file that was "linted", but with all the org mode files (which also showed the "problem"). I am writing to withdraw my question (my org mode setup is working), but also to mention that there appears to be some side-effect to running org-lint. This side-effect may prove be a latent bug that would affect future updates/revisions to org mode. Thank you. Frank. Emacs : GNU Emacs 25.2.1 (x86_64-w64-mingw32) of 2017-04-24 Package: Org mode version 9.1.2 (9.1.2-32-g271e58-elpaplus @ c:/USR/FJM/APP/.emacs.d/elpa/org-plus-contrib-20171106/)
Re: [O] ob-shell, output and continuation prompts
Hello, Michael Welle writes: > Hello Eric, > > Eric S Fraga writes: > >> On Tuesday, 28 Nov 2017 at 13:23, Michael Welle wrote: >>> I think that last one is what one would expect ;). Anyways, using sessions, >>> is there a way to get rid off of the shell's continuation prompts? >> >> PS2="" >> >> in the shell script? > does that work for you? I had to evaluate > (add-to-list 'tramp-remote-process-environment "PS2=> "). Otherwise > tramp/emacs would wait forever after sending the first line of the for > loop. oh, I should add that. Albeit the example I posted earlier runs locally, my goal is to execute the shell code on a remote machine. But the result is the same with both scenarios. #+BEGIN_SRC shell :session n42 :dir /localhost: :shebang "#!/bin/bash" for i in "aa" "bb" "cc" ; do echo "u: $i" done #+end_src Regards hmw
Re: [O] ob-shell, output and continuation prompts
Hello Eric, Eric S Fraga writes: > On Tuesday, 28 Nov 2017 at 13:23, Michael Welle wrote: >> I think that last one is what one would expect ;). Anyways, using sessions, >> is there a way to get rid off of the shell's continuation prompts? > > PS2="" > > in the shell script? does that work for you? I had to evaluate (add-to-list 'tramp-remote-process-environment "PS2=> "). Otherwise tramp/emacs would wait forever after sending the first line of the for loop. Regards hmw
Re: [O] ob-shell, output and continuation prompts
On Tuesday, 28 Nov 2017 at 13:23, Michael Welle wrote: > I think that last one is what one would expect ;). Anyways, using sessions, > is there a way to get rid off of the shell's continuation prompts? PS2="" in the shell script? -- Eric S Fraga via Emacs 27.0.50, Org release_9.1.3-168-g7455f4 signature.asc Description: PGP signature
[O] ob-shell, output and continuation prompts
Hello, this code block: #+BEGIN_SRC shell :session n42 :shebang "#!/bin/bash" for i in "aa" "bb" "cc" ; do echo "u: $i" done #+end_src produces this output when it first runs: #+RESULTS: ||||| | > | > | u: | aa | | u: | bb ||| | u: | cc ||| After the first run, subsequent runs produce this output: #+RESULTS: |||| | > | u: | aa | | u: | bb || | u: | cc || If I set :session to none the output is always like follows: #+RESULTS: | u: | aa | | u: | bb | | u: | cc | I think that last one is what one would expect ;). Anyways, using sessions, is there a way to get rid off of the shell's continuation prompts? Regards hmw
[O] ob-shell and remote shells
Hello, I want to execute shell blocks like follows: #+BEGIN_SRC shell :session n42 :dir /127.0.0.1: :shebang "#!/bin/bash" echo los echo $SHELL echo $BASH echo ready #+end_src The trouble is that the shebang property doesn't work in this case. The script is executed with the login shell of the user and fails because of syntax errors (for instance, if bashisms are used in the script). With my minimal and dangerous knowledge about Org's source code ;), I think the following might work (from ob-shell.el): (defun org-babel-sh-initiate-session (&optional session _params) "Initiate a session named SESSION according to PARAMS." (when (and session (not (string= session "none"))) (save-window-excursion (or (org-babel-comint-buffer-livep session) (progn (let ((explicit-shell-file-name (xxx))) (shell session)) ;; Needed for Emacs 23 since the marker is initially ;; undefined and the filter functions try to use it without ;; checking. (set-marker comint-last-output-start (point)) (get-buffer (current-buffer))) Note the let form. Further tasks that have to be done is to add the shebang key to _params, which I hope is available at all places where o-b-s-i-s is evaluated. Further at (xxx) a regexp etc. is needed to transform the shebang line to a shell path suitable for e-s-f-n. Any opinions, please? Depending on the opinions I will implement the approach this week and see if it works as expected. Regards hmw