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

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

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