Re: [O] [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