emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Daniele Pizzolli <dan@toel.it>
To: "Charles C. Berry" <ccberry@ucsd.edu>
Cc: org-mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
Date: Wed, 04 Feb 2015 09:59:06 +0100	[thread overview]
Message-ID: <86386mxdb9.fsf@me.localhost.invalid> (raw)
In-Reply-To: <alpine.OSX.2.00.1502030952420.602@charles-berrys-macbook.local> (Charles C. Berry's message of "Tue, 3 Feb 2015 10:19:00 -0800")

Hello Charles,

"Charles C. Berry" writes:

> Further Daniele's response to '[bug] Removing the Babel results':
>
>     http://article.gmane.org/gmane.emacs.orgmode/94604
>
> See below.
>
>> 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:

Thanks for your reasoning and conclusion.

>
> #+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):")))

(y/n) seems to be redundant: y-or-n-p prints the options by itself.

>      (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'.

Seems reasonable to me.  But I still think that one-or-many does not
have a lot of sense since there is the one-case function already.

Is it possible to call it by something like C-u C-u M-x
org-babel-remove-result-one-or-many or by a custom keystroke and avoid
the interactive prompt and have it to clean all the result keeping the
keyword (without writing a function or using lambda)?

As a novice I like interactive prompt because you can be lead through
the choices, but I do not want to be annoyed by them when I become
expert and have the answer ready and it is almost always the same one.

If not, no worries, I think I will wrap in a custom one.

Thanks again,
Daniele

      reply	other threads:[~2015-02-04  8:59 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
2015-02-04  8:59             ` Daniele Pizzolli [this message]

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=86386mxdb9.fsf@me.localhost.invalid \
    --to=dan@toel.it \
    --cc=ccberry@ucsd.edu \
    --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).