Hello,
Kaushal Modi writes:
> 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:
[...]
> Then for whatever reason, they choose to delete the RESULTS manually.. and
> the blank
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
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
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
