Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
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
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
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
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
Charles C. Berry ccbe...@ucsd.edu writes: [discussion of extra whitespace bug deleted] There is now a bugfix on master. I've also added 'interactive' to `org-babel-remove-inline-result'. Thanks. Would you mind providing a test case for this? Regards,
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
On Sat, 31 Jan 2015, Nicolas Goaziou wrote: Charles C. Berry ccbe...@ucsd.edu writes: [discussion of extra whitespace bug deleted] There is now a bugfix on master. I've also added 'interactive' to `org-babel-remove-inline-result'. Thanks. Would you mind providing a test case for this? I just pushed one to master. Chuck
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
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
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
Charles C. Berry ccbe...@ucsd.edu writes: On Sat, 31 Jan 2015, Nicolas Goaziou wrote: Thanks. Would you mind providing a test case for this? I just pushed one to master. Thank you. Regards,
Re: [O] [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result
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
