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
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
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
# 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 t
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
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
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 it
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
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,
espe
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)
>
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_e
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 pyt
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
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:
>
>
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 w
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 h
> 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
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 o
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
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 fil
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=""
>>
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 yo
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
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 ru
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 u
25 matches
Mail list logo
