Re: [O] ob-shell and remote shells

[Michael Welle]

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

[numbch...@gmail.com]

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 ( 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

[Adrian Bradd]

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

[Noam Postavsky]

# 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

[Kaushal Modi]

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

[Nicolas Goaziou]

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

[Nicolas Goaziou]

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

[Nicolas Goaziou]

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

[Kaushal Modi]

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

[Nicolas Goaziou]

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

[Kaushal Modi]

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

[Kaushal Modi]

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

[Nicolas Goaziou]

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]

[Nick Dokos]

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

[Ruy Exel]

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]

[Thierry Banel]

  
  
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

[Berry, Charles]

> 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]

[Roger Mason]

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/)]

[Nicolas Goaziou]

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/)]

[Francis J. Monari, Esquire]

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

[Michael Welle]

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

[Michael Welle]

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

[Eric S Fraga]

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

[Michael Welle]

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

[Michael Welle]

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 ( 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