From: "Charles C. Berry" <ccberry@ucsd.edu>
To: Nicolas Goaziou <mail@nicolasgoaziou.fr>
Cc: Aaron Ecay <aaronecay@gmail.com>,
Andreas Leha <andreas.leha@med.uni-goettingen.de>,
emacs-orgmode@gnu.org, Ista Zahn <istazahn@gmail.com>,
mcg <giepen.m@googlemail.com>
Subject: Re: [PATCH] inline src block results can be removed
Date: Sat, 15 Nov 2014 12:22:22 -0800 [thread overview]
Message-ID: <alpine.OSX.2.00.1411151035040.796@charles-berrys-macbook.local> (raw)
In-Reply-To: <87sihltt3v.fsf@selenimh.mobile.lan>
On Fri, 14 Nov 2014, Nicolas Goaziou wrote:
> "Charles C. Berry" <ccberry@ucsd.edu> writes:
>
>> More patches (as you can see). Now ox.el, ob-core.el, and ob-exp.el
>> are patched.
>
> Thanks.
>
[skipping to the bottom - omitting useful critiques of code and
opinions about strategy and tactics from Nicolas]
> WDYT?
After staring at `org-babel-insert-result' for too long, I am beginning to
feel like Alice in Wonderland. As currently implemented, inline src blocks
are somewhere between fragile and broken. I worry about making them even
more fragile, the logic in `org-babel-insert-result' has plenty of twists
ans turns, and I cannot commit the effort to dig deeply into them. So I am
looking for an easy way out.
For now, I'd be willing to make patches that will allow removal of the
inline src block results that do *not* involve these header args:
- :file <fn>
- :wrap <wrapper>
- :results latex html drawer org code
which I can do barely touching `org-babel-insert-result' and this
simplifies matters a lot.
I propose to do this by using the patches of ox.el and ob-exp.el from
my last post. For ob-core.el, I would
- leave defcustom org-babel-inline-wrap as "=%s=" (or use defconst - I
do not have a strong opinion either way).
- allow replacement of exising results in `org-babel-insert-result'
like so
#+BEGIN_EXAMPLE
- (existing-result (unless inlinep
-(org-babel-where-is-src-block-result
+ (existing-result (if inlinep
+(org-babel-delete-results-macro)
+ (org-babel-where-is-src-block-result
#+END_EXAMPLE
and defun `org-babel-delete-results-macro' per Nicolas' suggestions
for `org-babel-delete-babel-snippet' (from earlier patch) to use
`org-element-context' and friends (and not mess with export
snippets).
- modify `org-babel-examplify-region' along these lines
#+BEGIN_SRC emacs-lisp
(insert
(replace-regexp-in-string
"," "\\,"
(format
(concat "{{{results("
org-babel-inline-result-wrap
")}}}"
(prog1 (buffer-substring beg end)
(delete-region beg end))))
nil t))
#+END_SRC
I believe that this is simple enough to avoid breaking idioms that
folks might use now.
As for the choice between "=%s=" and "%s", the latter was hard coded
until f285b7ed3d097dd1cbb55fa3c31bc92aa0149054 in February 2013 and
has been the default since. It also parallels what happens with
handling src block results. Going forward I do not think this
behavior should change.
I have too litle experience with #+MACROs to know if Aaron's
suggestion to let the user customize the macro is opening up potential
issues when users get `creative'.
I can do what I've outlined in the coming days.
If it is felt that more retooling of `org-babel-insert-results' is really
needed, I can get to it early next year. In fact, I'll be out of email
range from late this month till then, so any problems I create now will
have to wait till then for me to work on them.
Thanks for the critique of my earlier patches and your thoughts.
Best,
Chuck
next prev parent reply other threads:[~2014-11-15 20:22 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-12 0:49 [PATCH] inline src block results can be removed Charles C. Berry
2014-11-12 1:10 ` Andreas Leha
2014-11-12 6:58 ` Charles C. Berry
2014-11-12 19:34 ` Aaron Ecay
2014-11-12 23:47 ` Charles C. Berry
2014-11-13 17:48 ` Nicolas Goaziou
2014-11-13 19:06 ` Andreas Leha
2014-11-14 17:43 ` Charles C. Berry
2014-11-14 20:39 ` Nicolas Goaziou
2014-11-14 23:04 ` Aaron Ecay
2014-11-16 0:10 ` Nicolas Goaziou
2014-11-15 20:22 ` Charles C. Berry [this message]
2014-11-16 23:23 ` Nicolas Goaziou
2014-11-24 9:48 ` Daniele Pizzolli
2014-11-24 10:18 ` Andreas Leha
2015-01-13 0:48 ` New patches WAS " Charles C. Berry
2015-01-16 22:41 ` Nicolas Goaziou
2015-01-19 3:22 ` Charles C. Berry
2015-01-19 17:53 ` Nicolas Goaziou
2015-01-19 19:31 ` Charles C. Berry
2015-01-20 23:30 ` Nicolas Goaziou
2015-01-22 3:07 ` Charles C. Berry
2015-01-22 23:08 ` Nicolas Goaziou
2015-01-24 22:47 ` Charles C. Berry
2015-01-25 1:14 ` Aaron Ecay
2015-01-25 5:01 ` Charles C. Berry
2015-01-29 20:31 ` Charles C. Berry
2015-01-17 3:22 ` Aaron Ecay
2015-01-17 22:20 ` Nicolas Goaziou
2015-01-18 19:13 ` Aaron Ecay
2015-01-18 22:34 ` Nicolas Goaziou
2015-01-18 22:55 ` Aaron Ecay
-- strict thread matches above, loose matches on Subject: below --
2014-11-24 11:12 Daniele Pizzolli
2014-11-25 8:04 ` Daniele Pizzolli
2014-11-25 9:52 ` Andreas Leha
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.1411151035040.796@charles-berrys-macbook.local \
--to=ccberry@ucsd.edu \
--cc=aaronecay@gmail.com \
--cc=andreas.leha@med.uni-goettingen.de \
--cc=emacs-orgmode@gnu.org \
--cc=giepen.m@googlemail.com \
--cc=istazahn@gmail.com \
--cc=mail@nicolasgoaziou.fr \
/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).