idempotency and inconsistency for org-babel-remove-inline-result

idempotency and inconsistency for org-babel-remove-inline-result

[Daniele Pizzolli]

Hello,

I really like the new inline results.  Thanks for this new cool feature.
I have only a few problems with it.

Is there a way to evaluate a buffer an then remove inline results or
better, to get the very same buffer after:

(org-babel-execute-buffer)
(org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))

Every call add an extra white space:

Original:

1 + 4 in R is src_R[:exports results]{1+4}.

After (org-babel-execute-buffer):

1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}}.

After: (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))

1 + 4 in R is src_R[:exports results]{1+4} .

After (org-babel-execute-buffer):

1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}} .

And so on...

I see that the function docs says: Extraneous leading whitespace is
trimmed. Is this the intended result?


Also, is there anything that prevents to make
org-babel-remove-inline-result interactive as is
org-babel-remove-result?  Wwhy not have also
org-babel-remove-inline-result-one-or-many and
org-babel-remove-all-result-one-or-many to remove all the babel result
with one function call?

I do no not know lisp a lot, but I can try to submit a patch if you
agree that will be useful.

Thanks in advance,
Daniele

Re: idempotency and inconsistency for org-babel-remove-inline-result

[Charles C. Berry]

On Fri, 30 Jan 2015, Daniele Pizzolli wrote:

> Hello,
>
> I really like the new inline results.  Thanks for this new cool feature.
> I have only a few problems with it.
>

Thanks for your feedback.

> Is there a way to evaluate a buffer an then remove inline results or
> better, to get the very same buffer after:
>
> (org-babel-execute-buffer)
> (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))
>
> Every call add an extra white space:
>
> Original:
>
> 1 + 4 in R is src_R[:exports results]{1+4}.
>
> After (org-babel-execute-buffer):
>
> 1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}}.
>
> After: (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result))
>
> 1 + 4 in R is src_R[:exports results]{1+4} .
>
> After (org-babel-execute-buffer):
>
> 1 + 4 in R is src_R[:exports results]{1+4} {{{results(5)}}} .
>
> And so on...
>
> I see that the function docs says: Extraneous leading whitespace is
> trimmed. Is this the intended result?
>

It is intended to remove `extraneous' whitespace. But the way
`extraneous' is operationalized leaves something to be desired if
users wish to do as you have done. Maybe preserving whitespace (if any)
after the result and deleting all that is before it might work.

I'll take a look at changing the defn to deal with your ECM.


>
> Also, is there anything that prevents to make
> org-babel-remove-inline-result interactive as is
> org-babel-remove-result?

AFAICS, no.

> Wwhy not have also
> org-babel-remove-inline-result-one-or-many and
> org-babel-remove-all-result-one-or-many to remove all the babel result
> with one function call?

Easy enough, but is this really needed? What about call block/line 
results?

>
> I do no not know lisp a lot, but I can try to submit a patch if you
> agree that will be useful.
>

The main issue (IMO) is figuring out what whitespace to delete around
a `{{{results(...)}}}' macro. I can get to this in a day or so, but
feel free to send a patch.

Chuck

Re: idempotency and inconsistency for org-babel-remove-inline-result

[Daniele Pizzolli]

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]

Hello Charles,

"Charles C. Berry" writes:

> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>
>> Hello,
>>
>> I really like the new inline results.  Thanks for this new cool feature.
>> I have only a few problems with it.
>>
>
> Thanks for your feedback.

Nice to hear.

>> Is there a way to evaluate a buffer an then remove inline results or
>> better, to get the very same buffer after:

[]

>> I see that the function docs says: Extraneous leading whitespace is
>> trimmed. Is this the intended result?
>
> It is intended to remove `extraneous' whitespace. But the way
> `extraneous' is operationalized leaves something to be desired if
> users wish to do as you have done. Maybe preserving whitespace (if any)
> after the result and deleting all that is before it might work.
>
> I'll take a look at changing the defn to deal with your ECM.

Thanks, see later.

>>
>> Also, is there anything that prevents to make
>> org-babel-remove-inline-result interactive as is
>> org-babel-remove-result?
>
> AFAICS, no.

Ok, patch attached.

>> Wwhy not have also
>> org-babel-remove-inline-result-one-or-many and
>> org-babel-remove-all-result-one-or-many to remove all the babel result
>> with one function call?
>
> Easy enough, but is this really needed? What about call block/line
> results?

This is useful for me because I want to easily discard the results to
have the commit with only the changes in the source.  I hope others find
this a reasonable facility.  It is like a 'make clean' for your org
files.

Patch attached.  I am not sure about the default of discarding keyword
Deleting the result line can cause some disorder, but it is the default
in org-babel-remove-result.  Also the naming can be confusing.

>> I do no not know lisp a lot, but I can try to submit a patch if you
>> agree that will be useful.
>>
>
> The main issue (IMO) is figuring out what whitespace to delete around
> a `{{{results(...)}}}' macro. I can get to this in a day or so, but
> feel free to send a patch.

This is above my lisp coding abilities, with too many org-related
function to get lost into org-babel-remove-inline-result...  I can wait,
but if you have any pointer I will be happy to do some exploration.

Thanks again,
Daniele


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ob-core.el-add-interactive-to-org-babel-remove-inlin.patch --]
[-- Type: text/x-diff, Size: 956 bytes --]

From 4f484ac1f9ae4adcf5551bf6e77e5545f124f11b Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli <dan@toel.it>
Date: Fri, 30 Jan 2015 20:57:15 +0100
Subject: [PATCH 1/2] ob-core.el: add interactive to
 `org-babel-remove-inline-result'

* lisp/ob-core.el (org-babel-remove-inline-result): Add interactive.

TINYCHANGE
---
 lisp/ob-core.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index fcc44c1..ac9f63b 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2324,6 +2324,7 @@ INFO may provide the values of these header arguments (in the
   "Remove the result of the current inline-src-block or babel call.
 The result must be wrapped in a `results' macro to be
   removed. Extraneous leading whitespace is trimmed."
+  (interactive)
   (let* ((el (org-element-context))
 	 (post-blank (org-element-property :post-blank el)))
     (when (memq (org-element-type el) '(inline-src-block inline-babel-call))
-- 
2.1.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-ob-core.el-Add-org-babel-remove-result-all.patch --]
[-- Type: text/x-diff, Size: 1199 bytes --]

From b108f6b8dfd28d6c6ebcdfcabb428438fe348ad9 Mon Sep 17 00:00:00 2001
From: Daniele Pizzolli <dan@toel.it>
Date: Fri, 30 Jan 2015 23:28:27 +0100
Subject: [PATCH 2/2] ob-core.el: Add `org-babel-remove-result-all'

* lisp/ob-core.el (org-babel-remove-result-all): New interactive
  function.

TINYCHANGE
---
 lisp/ob-core.el | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index ac9f63b..e09863d 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2348,6 +2348,16 @@ in the buffer."
       (org-babel-map-src-blocks nil (org-babel-remove-result))
     (org-babel-remove-result)))
 
+(defun org-babel-remove-result-all (x)
+  "Remove the results of all the source blocks and the results of all inline sources.
+If called with a prefix argument, keep the keyword in result
+blocks."
+  (interactive "P")
+  (if x
+      (org-babel-map-src-blocks nil (org-babel-remove-result nil t))
+    (org-babel-map-src-blocks nil (org-babel-remove-result)))
+  (org-babel-map-inline-src-blocks nil (org-babel-remove-inline-result)))
+
 (defun org-babel-result-end ()
   "Return the point at the end of the current set of results."
   (save-excursion
-- 
2.1.4

[RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Charles C. Berry]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2113 bytes --]


RFC: the patch to `org-babel-remove-inline-result-one-or-many' 
removes inline results, too.

Do you see any bad consequences?

On Fri, 30 Jan 2015, Daniele Pizzolli wrote:

> Hello Charles,
>
> "Charles C. Berry" writes:
>
>> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>>

[discussion of extra whitespace bug deleted]

There is now a bugfix on master. I've also added 'interactive' to 
`org-babel-remove-inline-result'.

>
>>> Is there a way to evaluate a buffer an then remove inline results or
>>> better, to get the very same buffer after:
>

Yes.

See attached patch which should clean *all* results (except `raw' results) 
from a buffer when `org-babel-remove-result-one-or-many' is called with a 
prefix.

Before pushing this, I'd like some feedback on the wisdom of doing what 
the patch does.

>>> Wwhy not have also
>>> org-babel-remove-inline-result-one-or-many and
>>> org-babel-remove-all-result-one-or-many to remove all the babel result
>>> with one function call?
>>
>> Easy enough, but is this really needed? What about call block/line
>> results?
>
> This is useful for me because I want to easily discard the results to
> have the commit with only the changes in the source.  I hope others find
> this a reasonable facility.  It is like a 'make clean' for your org
> files.

I think extending `org-babel-remove-all-result-one-or-many' to cover 
inline results is innocuous. So if nobody raises an objection, I will 
push the patch.

I got that you want to clean up your buffer. But an issue with adding 
more functions is 'feature bloat'. If you really need 
`org-babel-remove-result-all' and 
`org-babel-remove-inline-result-one-or-many' you can have private 
functions.

>
> Patch attached.

Thank you.

Regarding patches, if you haven't signed FSF copyright papers a TINYCHANGE 
is needed in the commit message.

> I am not sure about the default of discarding keyword
> Deleting the result line can cause some disorder, but it is the default
> in org-babel-remove-result.  Also the naming can be confusing.

Alas. Then there is the user error I have made of re-using names.

Best,

Chuck

[-- Attachment #2: remove inline results also --]
[-- Type: TEXT/PLAIN, Size: 1472 bytes --]

From af94ed1c07a914ba686076c83a08f80c3b21c32b Mon Sep 17 00:00:00 2001
From: Charles Berry <ccberry@ucsd.edu>
Date: Fri, 30 Jan 2015 19:14:51 -0800
Subject: [PATCH 2/2] ob-core.el: `org-babel-remove-result-one-or-many' removes
 inline results

* ob-core.el (org-babel-remove-result-one-or-many): Remove all results
  of babel executables, including inline results.
---
 lisp/ob-core.el | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index ceda1aa..6c8a587 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2339,13 +2339,16 @@ Leading whitespace is trimmed."
 		(org-element-property :post-blank el)))))))))
 
 (defun org-babel-remove-result-one-or-many (x)
-  "Remove the result of the current source block.
-If called with a prefix argument, remove all result blocks
-in the buffer."
+  "Remove the result of the current (inline) source block.
+If called with a prefix argument, remove all result blocks and
+macros in the buffer."
   (interactive "P")
   (if x
-      (org-babel-map-src-blocks nil (org-babel-remove-result))
-    (org-babel-remove-result)))
+      (org-babel-map-executables nil
+	(org-babel-remove-result)
+	(org-babel-remove-inline-result))
+    (org-babel-remove-result)
+    (org-babel-remove-inline-result)))
 
 (defun org-babel-result-end ()
   "Return the point at the end of the current set of results."
-- 
1.9.3 (Apple Git-50)

Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> [discussion of extra whitespace bug deleted]
>
> There is now a bugfix on master. I've also added 'interactive' to
> `org-babel-remove-inline-result'.

Thanks. Would you mind providing a test case for this?


Regards,

Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Daniele Pizzolli]

Hello Charles,

"Charles C. Berry" writes:

> RFC: the patch to `org-babel-remove-inline-result-one-or-many' removes
> inline results, too.
>
> Do you see any bad consequences?
>
> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>
>> Hello Charles,
>>
>> "Charles C. Berry" writes:
>>
>>> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>>>
>
> [discussion of extra whitespace bug deleted]
>
> There is now a bugfix on master. I've also added 'interactive' to
> `org-babel-remove-inline-result'.
>
>>
>>>> Is there a way to evaluate a buffer an then remove inline results or
>>>> better, to get the very same buffer after:
>>
>
> Yes.
>
> See attached patch which should clean *all* results (except `raw'
> results) from a buffer when `org-babel-remove-result-one-or-many' is
> called with a prefix.
>
> Before pushing this, I'd like some feedback on the wisdom of doing
> what the patch does.

Let me try to explain better my use case, that is not covered by this
patch, but was covered by mine.

Currently org-babel-remove-result has an optional argument to keep the
named block results at their position.  I will call this feature
clean-result.  I think that this is more useful that the default
remove-result.  The rationale is that removing the results will lead to
some inconsistencies if you remove and re-execute the buffer, for
details see:
http://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00872.html

So I will be happy if a native function take care of this use case.
Maybe a new function with clean in the name instead of remove will solve
this?  Or it will add additional confusion as the inline sources are
removed but the blocks cleaned...

Also, I do not really see the point of having
org-babel-remove-result-one-or-many, since the one case is already
covered by org-babel-remove-result, but maybe there is some additional
magic that I do not understand.

[skip the discussion about my previous patch]

>> Patch attached.
>
> Thank you.
>
> Regarding patches, if you haven't signed FSF copyright papers a
> TINYCHANGE is needed in the commit message.

Yes, there was a TINYCHANGE in the last line of the commit message!

Best,
Daniele

Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Charles C. Berry]

On Sat, 31 Jan 2015, Nicolas Goaziou wrote:

> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> [discussion of extra whitespace bug deleted]
>>
>> There is now a bugfix on master. I've also added 'interactive' to
>> `org-babel-remove-inline-result'.
>
> Thanks. Would you mind providing a test case for this?

I just pushed one to master.

Chuck

Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Charles C. Berry]

On Sat, 31 Jan 2015, Daniele Pizzolli wrote:

[discussing the RFC, now]

> Hello Charles,
>
> "Charles C. Berry" writes:
>
>> RFC: the patch to `org-babel-remove-inline-result-one-or-many' removes
>> inline results, too.
>>
>> Do you see any bad consequences?
>>
>> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>>
>>> Hello Charles,
>>>
>>> "Charles C. Berry" writes:
>>>
>>>> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>>>>
>>
>> [discussion of extra whitespace bug deleted]
>>
>> There is now a bugfix on master. I've also added 'interactive' to
>> `org-babel-remove-inline-result'.
>>
>>>
>>>>> Is there a way to evaluate a buffer an then remove inline results or
>>>>> better, to get the very same buffer after:
>>>
>>
>> Yes.
>>
>> See attached patch which should clean *all* results (except `raw'
>> results) from a buffer when `org-babel-remove-result-one-or-many' is
>> called with a prefix.
>>
>> Before pushing this, I'd like some feedback on the wisdom of doing
>> what the patch does.
>
> Let me try to explain better my use case, that is not covered by this
> patch, but was covered by mine.
>
> Currently org-babel-remove-result has an optional argument to keep the
> named block results at their position.  I will call this feature
> clean-result.  I think that this is more useful that the default
> remove-result.  The rationale is that removing the results will lead to
> some inconsistencies if you remove and re-execute the buffer, for
> details see:
> http://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00872.html
>
> So I will be happy if a native function take care of this use case.
> Maybe a new function with clean in the name instead of remove will solve
> this?  Or it will add additional confusion as the inline sources are
> removed but the blocks cleaned...
>

But why a `native' function? You know how to achieve this result and
can

1. add a customized function to your init file,
2. submit a snippet to Worg, and/or
3. contribute an *add on*, and/or
4. argue for changes/additions to the Org code base, what you call a
    `native' function.

Option 4 generates work for those who maintain Org code, so it needs
to be justified in terms of usefulness to other users and
issues in the code that it might fix or complicate.

Even if 4 is the right path, a decision is needed on whether to add
new functions, or change the behavior of existing functions (possibly
adding a new variable or customization). The latter might be cleaner,
but runs the risk of breaking someone's code.

Let's see what others add to this discussion.

> Also, I do not really see the point of having
> org-babel-remove-result-one-or-many, since the one case is already
> covered by org-babel-remove-result, but maybe there is some additional
> magic that I do not understand.
>

Just a matter of keymapping, I guess. Kill one [or all]:

 	[C-u] C-c C-v k


> [skip the discussion about my previous patch]
>
>>> Patch attached.
>>
>> Thank you.
>>
>> Regarding patches, if you haven't signed FSF copyright papers a
>> TINYCHANGE is needed in the commit message.
>
> Yes, there was a TINYCHANGE in the last line of the commit message!
>

My bad. Tired eyes. Sorry.

Chuck

Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Nicolas Goaziou]

"Charles C. Berry" <ccberry@ucsd.edu> writes:

> On Sat, 31 Jan 2015, Nicolas Goaziou wrote:
>>
>> Thanks. Would you mind providing a test case for this?
>
> I just pushed one to master.

Thank you.

Regards,

Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Charles C. Berry]

Further Daniele's response to '[bug] Removing the Babel results':

    http://article.gmane.org/gmane.emacs.orgmode/94604

See below.

On Sat, 31 Jan 2015, Charles C. Berry wrote:

> On Sat, 31 Jan 2015, Daniele Pizzolli wrote:
>
> [discussing the RFC, now]
>
>> Hello Charles,
>> 
>> "Charles C. Berry" writes:
>> 
>>> RFC: the patch to `org-babel-remove-inline-result-one-or-many' removes
>>> inline results, too.
>>> 
>>> Do you see any bad consequences?
>>> 
>>> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>>> 
>>>> Hello Charles,
>>>> 
>>>> "Charles C. Berry" writes:
>>>> 
>>>>> On Fri, 30 Jan 2015, Daniele Pizzolli wrote:
>>>>> 
>>> 
>>> [discussion of extra whitespace bug deleted]
>>> 
>>> There is now a bugfix on master. I've also added 'interactive' to
>>> `org-babel-remove-inline-result'.
>>> 
>>>> 
>>>>>> Is there a way to evaluate a buffer an then remove inline results or
>>>>>> better, to get the very same buffer after:
>>>> 
>>> 
>>> Yes.
>>> 
>>> See attached patch which should clean *all* results (except `raw'
>>> results) from a buffer when `org-babel-remove-result-one-or-many' is
>>> called with a prefix.
>>> 
>>> Before pushing this, I'd like some feedback on the wisdom of doing
>>> what the patch does.
>> 
>> Let me try to explain better my use case, that is not covered by this
>> patch, but was covered by mine.
>> 
>> Currently org-babel-remove-result has an optional argument to keep the
>> named block results at their position.  I will call this feature
>> clean-result.  I think that this is more useful that the default
>> remove-result.  The rationale is that removing the results will lead to
>> some inconsistencies if you remove and re-execute the buffer, for
>> details see:
>> http://lists.gnu.org/archive/html/emacs-orgmode/2013-09/msg00872.html
>> 
>> So I will be happy if a native function take care of this use case.
>> Maybe a new function with clean in the name instead of remove will solve
>> this?  Or it will add additional confusion as the inline sources are
>> removed but the blocks cleaned...
>> 
>
> But why a `native' function? You know how to achieve this result and
> can
>
> 1. add a customized function to your init file,
> 2. submit a snippet to Worg, and/or
> 3. contribute an *add on*, and/or
> 4. argue for changes/additions to the Org code base, what you call a
>   `native' function.
>
> Option 4 generates work for those who maintain Org code, so it needs
> to be justified in terms of usefulness to other users and
> issues in the code that it might fix or complicate.
>
> Even if 4 is the right path, a decision is needed on whether to add
> new functions, or change the behavior of existing functions (possibly
> adding a new variable or customization). The latter might be cleaner,
> but runs the risk of breaking someone's code.

The latter notion is along these lines:

#+BEGIN_SRC emacs-lisp
   (defun org-babel-remove-result-one-or-many (x &optional keep-keyword)
     "Remove the result of the current source block.
   If called with a prefix argument, remove all result blocks and
   results macros in the buffer. When KEEP-KEYWORD is non-nil, allow
   RESULTS keywords to remain."
     (interactive (list current-prefix-arg
                        (y-or-n-p "Keep RESULTS keyword(y/n):")))
     (if x
         (org-babel-map-executables nil
           (org-babel-remove-result nil keep-keyword)
           (org-babel-remove-inline-result))
       (org-babel-remove-result nil keep-keyword)
       (org-babel-remove-inline-result)))
#+END_SRC

which seems to handle Sebastien's `bug' if the user responds with 'y' (or 
a calling function has a non-nil `keep-keyword'.

It passes

 	make test

However, there remains the need to add something to 
testing/lisp/test-ob.el.

WDYT?

Chuck

Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result

[Daniele Pizzolli]

Hello Charles,

"Charles C. Berry" writes:

> Further Daniele's response to '[bug] Removing the Babel results':
>
>     http://article.gmane.org/gmane.emacs.orgmode/94604
>
> See below.
>
>> But why a `native' function? You know how to achieve this result and
>> can
>>
>> 1. add a customized function to your init file,
>> 2. submit a snippet to Worg, and/or
>> 3. contribute an *add on*, and/or
>> 4. argue for changes/additions to the Org code base, what you call a
>>   `native' function.
>>
>> Option 4 generates work for those who maintain Org code, so it needs
>> to be justified in terms of usefulness to other users and
>> issues in the code that it might fix or complicate.
>>
>> Even if 4 is the right path, a decision is needed on whether to add
>> new functions, or change the behavior of existing functions (possibly
>> adding a new variable or customization). The latter might be cleaner,
>> but runs the risk of breaking someone's code.
>
> The latter notion is along these lines:

Thanks for your reasoning and conclusion.

>
> #+BEGIN_SRC emacs-lisp
>    (defun org-babel-remove-result-one-or-many (x &optional keep-keyword)
>      "Remove the result of the current source block.
>    If called with a prefix argument, remove all result blocks and
>    results macros in the buffer. When KEEP-KEYWORD is non-nil, allow
>    RESULTS keywords to remain."
>      (interactive (list current-prefix-arg
>                         (y-or-n-p "Keep RESULTS keyword(y/n):")))

(y/n) seems to be redundant: y-or-n-p prints the options by itself.

>      (if x
>          (org-babel-map-executables nil
>            (org-babel-remove-result nil keep-keyword)
>            (org-babel-remove-inline-result))
>        (org-babel-remove-result nil keep-keyword)
>        (org-babel-remove-inline-result)))
> #+END_SRC
>
> which seems to handle Sebastien's `bug' if the user responds with 'y' (or 
> a calling function has a non-nil `keep-keyword'.

Seems reasonable to me.  But I still think that one-or-many does not
have a lot of sense since there is the one-case function already.

Is it possible to call it by something like C-u C-u M-x
org-babel-remove-result-one-or-many or by a custom keystroke and avoid
the interactive prompt and have it to clean all the result keeping the
keyword (without writing a function or using lambda)?

As a novice I like interactive prompt because you can be lead through
the choices, but I do not want to be annoyed by them when I become
expert and have the answer ready and it is almost always the same one.

If not, no worries, I think I will wrap in a custom one.

Thanks again,
Daniele