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

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

[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

[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

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

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

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

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

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

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

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

[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

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 >

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

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++")

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

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.

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

[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

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

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?

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

[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

[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