From: Nicolas Goaziou <mail@nicolasgoaziou.fr>
To: "Charles C. Berry" <ccberry@ucsd.edu>
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: Mon, 17 Nov 2014 00:23:37 +0100 [thread overview]
Message-ID: <87zjbqrapy.fsf@nicolasgoaziou.fr> (raw)
In-Reply-To: <alpine.OSX.2.00.1411151035040.796@charles-berrys-macbook.local> (Charles C. Berry's message of "Sat, 15 Nov 2014 12:22:22 -0800")
"Charles C. Berry" <ccberry@ucsd.edu> writes:
> 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.
IMO, we're too much focused on the implementation details. We ought to
agree on what should be done first. For example, considering
`org-babel-insert-result' and its RESULT-PARAMS argument, I think the
following makes sense:
| Param | Example output |
|---------+-----------------------------------|
| default | {{{results(42)}}} |
| file | {{{results(file:something.pdf)}}} |
| list | |
| raw | 42 |
| drawer | |
| org | {{{results(src_org{...})}}} |
| html | {{{results(@@html:...@@)}}} |
| latex | {{{results(@@latex:...@@)}}} |
| code | {{{results(src_xxx{...})}}} |
Basically, it should be possible to remove any kind of result using
"results" macro, with the exception of "raw". "list" and "drawer" can
be ignored since there is no inline equivalent.
Another option for "drawer" is to also use export snippets. So,
basically, "drawer something" would generate
{{{results(@@something:...@@)}}}.
> 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).
`org-babel-inline-wrap' as a defcustom is fine if you hardcode
{{{results(...)}}} wrapping at a higher level.
> - 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
But this is unrelated to "examplify". Wrapping should probably be
a dedicated function systematically called on results from an inline
block.
> 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.
It's going to be difficult not to alter `org-babel-insert-results' since
the plan is to change completely how inline source blocks are handled.
There's no rush, however. Non-removable results from inline source
blocks have been there for a long time.
Regards,
next prev parent reply other threads:[~2014-11-16 23:23 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
2014-11-16 23:23 ` Nicolas Goaziou [this message]
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=87zjbqrapy.fsf@nicolasgoaziou.fr \
--to=mail@nicolasgoaziou.fr \
--cc=aaronecay@gmail.com \
--cc=andreas.leha@med.uni-goettingen.de \
--cc=ccberry@ucsd.edu \
--cc=emacs-orgmode@gnu.org \
--cc=giepen.m@googlemail.com \
--cc=istazahn@gmail.com \
/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).