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

["Charles C. Berry" <ccberry@ucsd.edu>]

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