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