From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles C. Berry" Subject: [RFC] removing all results WAS: Re: idempotency ... org-babel-remove-inline-result Date: Fri, 30 Jan 2015 20:13:38 -0800 Message-ID: References: <86fvasqmpb.fsf@me.localhost.invalid> <86mw4zuav2.fsf@me.localhost.invalid> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1098037608-1422677619=:2444" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHPRg-00068M-D0 for emacs-orgmode@gnu.org; Fri, 30 Jan 2015 23:14:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YHPRb-0002xh-Cq for emacs-orgmode@gnu.org; Fri, 30 Jan 2015 23:14:08 -0500 Received: from iport-acv6-out.ucsd.edu ([132.239.0.13]:46928) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YHPRa-0002v2-U0 for emacs-orgmode@gnu.org; Fri, 30 Jan 2015 23:14:03 -0500 In-Reply-To: <86mw4zuav2.fsf@me.localhost.invalid> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Daniele Pizzolli Cc: org-mode mailing list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1098037608-1422677619=:2444 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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. >>> Wwhy not have also >>> org-babel-remove-inline-result-one-or-many and >>> org-babel-remove-all-result-one-or-many to remove all the babel result >>> with one function call? >> >> Easy enough, but is this really needed? What about call block/line >> results? > > This is useful for me because I want to easily discard the results to > have the commit with only the changes in the source. I hope others find > this a reasonable facility. It is like a 'make clean' for your org > files. I think extending `org-babel-remove-all-result-one-or-many' to cover inline results is innocuous. So if nobody raises an objection, I will push the patch. I got that you want to clean up your buffer. But an issue with adding more functions is 'feature bloat'. If you really need `org-babel-remove-result-all' and `org-babel-remove-inline-result-one-or-many' you can have private functions. > > Patch attached. Thank you. Regarding patches, if you haven't signed FSF copyright papers a TINYCHANGE is needed in the commit message. > I am not sure about the default of discarding keyword > Deleting the result line can cause some disorder, but it is the default > in org-babel-remove-result. Also the naming can be confusing. Alas. Then there is the user error I have made of re-using names. Best, Chuck --0-1098037608-1422677619=:2444 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=0002-ob-core.el-org-babel-remove-result-one-or-many-remov.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: remove inline results also Content-Disposition: attachment; filename=0002-ob-core.el-org-babel-remove-result-one-or-many-remov.patch RnJvbSBhZjk0ZWQxYzA3YTkxNGJhNjg2MDc2YzgzYTA4ZjgwYzNiMjFjMzJi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogQ2hhcmxlcyBCZXJy eSA8Y2NiZXJyeUB1Y3NkLmVkdT4NCkRhdGU6IEZyaSwgMzAgSmFuIDIwMTUg MTk6MTQ6NTEgLTA4MDANClN1YmplY3Q6IFtQQVRDSCAyLzJdIG9iLWNvcmUu ZWw6IGBvcmctYmFiZWwtcmVtb3ZlLXJlc3VsdC1vbmUtb3ItbWFueScgcmVt b3Zlcw0KIGlubGluZSByZXN1bHRzDQoNCiogb2ItY29yZS5lbCAob3JnLWJh YmVsLXJlbW92ZS1yZXN1bHQtb25lLW9yLW1hbnkpOiBSZW1vdmUgYWxsIHJl c3VsdHMNCiAgb2YgYmFiZWwgZXhlY3V0YWJsZXMsIGluY2x1ZGluZyBpbmxp bmUgcmVzdWx0cy4NCi0tLQ0KIGxpc3Avb2ItY29yZS5lbCB8IDEzICsrKysr KysrLS0tLS0NCiAxIGZpbGUgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspLCA1 IGRlbGV0aW9ucygtKQ0KDQpkaWZmIC0tZ2l0IGEvbGlzcC9vYi1jb3JlLmVs IGIvbGlzcC9vYi1jb3JlLmVsDQppbmRleCBjZWRhMWFhLi42YzhhNTg3IDEw MDY0NA0KLS0tIGEvbGlzcC9vYi1jb3JlLmVsDQorKysgYi9saXNwL29iLWNv cmUuZWwNCkBAIC0yMzM5LDEzICsyMzM5LDE2IEBAIExlYWRpbmcgd2hpdGVz cGFjZSBpcyB0cmltbWVkLiINCiAJCShvcmctZWxlbWVudC1wcm9wZXJ0eSA6 cG9zdC1ibGFuayBlbCkpKSkpKSkpKQ0KIA0KIChkZWZ1biBvcmctYmFiZWwt cmVtb3ZlLXJlc3VsdC1vbmUtb3ItbWFueSAoeCkNCi0gICJSZW1vdmUgdGhl IHJlc3VsdCBvZiB0aGUgY3VycmVudCBzb3VyY2UgYmxvY2suDQotSWYgY2Fs bGVkIHdpdGggYSBwcmVmaXggYXJndW1lbnQsIHJlbW92ZSBhbGwgcmVzdWx0 IGJsb2Nrcw0KLWluIHRoZSBidWZmZXIuIg0KKyAgIlJlbW92ZSB0aGUgcmVz dWx0IG9mIHRoZSBjdXJyZW50IChpbmxpbmUpIHNvdXJjZSBibG9jay4NCitJ ZiBjYWxsZWQgd2l0aCBhIHByZWZpeCBhcmd1bWVudCwgcmVtb3ZlIGFsbCBy ZXN1bHQgYmxvY2tzIGFuZA0KK21hY3JvcyBpbiB0aGUgYnVmZmVyLiINCiAg IChpbnRlcmFjdGl2ZSAiUCIpDQogICAoaWYgeA0KLSAgICAgIChvcmctYmFi ZWwtbWFwLXNyYy1ibG9ja3MgbmlsIChvcmctYmFiZWwtcmVtb3ZlLXJlc3Vs dCkpDQotICAgIChvcmctYmFiZWwtcmVtb3ZlLXJlc3VsdCkpKQ0KKyAgICAg IChvcmctYmFiZWwtbWFwLWV4ZWN1dGFibGVzIG5pbA0KKwkob3JnLWJhYmVs LXJlbW92ZS1yZXN1bHQpDQorCShvcmctYmFiZWwtcmVtb3ZlLWlubGluZS1y ZXN1bHQpKQ0KKyAgICAob3JnLWJhYmVsLXJlbW92ZS1yZXN1bHQpDQorICAg IChvcmctYmFiZWwtcmVtb3ZlLWlubGluZS1yZXN1bHQpKSkNCiANCiAoZGVm dW4gb3JnLWJhYmVsLXJlc3VsdC1lbmQgKCkNCiAgICJSZXR1cm4gdGhlIHBv aW50IGF0IHRoZSBlbmQgb2YgdGhlIGN1cnJlbnQgc2V0IG9mIHJlc3VsdHMu Ig0KLS0gDQoxLjkuMyAoQXBwbGUgR2l0LTUwKQ0KDQo= --0-1098037608-1422677619=:2444--