From: "Charles C. Berry" <ccberry@ucsd.edu>
To: Daniele Pizzolli <dan@toel.it>
Cc: org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
Date: Tue, 3 Feb 2015 10:19:00 -0800 [thread overview]
Message-ID: <alpine.OSX.2.00.1502030952420.602@charles-berrys-macbook.local> (raw)
In-Reply-To: <alpine.OSX.2.00.1501311118260.426@charles-berrys-macbook.local>
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
next prev parent reply other threads:[~2015-02-03 18:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-30 16:04 idempotency and inconsistency for org-babel-remove-inline-result Daniele Pizzolli
2015-01-30 19:13 ` Charles C. Berry
2015-01-30 23:06 ` Daniele Pizzolli
2015-01-31 4:13 ` [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result Charles C. Berry
2015-01-31 8:34 ` Nicolas Goaziou
2015-01-31 19:08 ` Charles C. Berry
2015-01-31 23:05 ` Nicolas Goaziou
2015-01-31 11:31 ` Daniele Pizzolli
2015-01-31 20:00 ` Charles C. Berry
2015-02-03 18:19 ` Charles C. Berry [this message]
2015-02-04 8:59 ` Daniele Pizzolli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.OSX.2.00.1502030952420.602@charles-berrys-macbook.local \
--to=ccberry@ucsd.edu \
--cc=dan@toel.it \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).