emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: emacs-orgmode@gnu.org
Subject: Re: question about capture templates
Date: Mon, 21 Feb 2011 20:59:21 -0800	[thread overview]
Message-ID: <87r5b0d5qu.fsf@berkeley.edu> (raw)
In-Reply-To: AANLkTinSDBGiBB3UKxkkuH6CddWJDr=B12Bhzaj0NGir@mail.gmail.com

"Filippo A. Salustri" <salustri@ryerson.ca> writes:

> org-capture clearly has the original buffer handy (for %a
> stuff) yet I can't get it out of there without hacking the org code, which I
> am loathe to do.

I too was in a situation just today where I was calling org-capture
programatically, and needed access to stuff in the calling environment.
My solution (which may not be very good, and may not work for you) is to
dynamically scope the calling environment stuff that I need into the
org-capture call, like so:

#+begin_src emacs-lisp
; in the calling code, I scope some val I need into `foo...'
(let ((foo some-val-I-need))
  (org-capture nil "tm"))
#+end_src

Then, in the template identified by "tm", I have S-expression expansion
that operates on foo, even though it wasn't explicitly passed as a
parameter, e.g.:

* My capture template
  The car of foo is %(car foo).
  The cdr of foo is %(cdr foo).
  %a
  etc. ...

This works well enough for me, though it may feel kind of icky, since
from the template writer's perspective, `foo' looks like a global
variable whose value could be coming from anywhere. Accordingly, then,
this solution is mostly useful if you know that you're going to be using
the template via custom Elisp calls to org-capture, and not via the
usual capture interface, so that you can guarantee that `foo' has a
useful value when the template is expanded.

One gotcha: S-expressions in templates are apparently always evaluated
as function calls -- you can't just directly access a string value, like
%(foo).

Hope that's helpful!

Richard

P.S. Since you say you have Scheme experience: note that this solution
would NOT work in Scheme, since Scheme, unlike Emacs Lisp, is lexically
scoped.

next prev parent reply	other threads:[~2011-02-22  4:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-21 15:08 question about capture templates Filippo A. Salustri
2011-02-21 15:29 ` Sébastien Vauban
2011-02-21 16:32   ` Richard Lawrence
2011-02-21 22:14     ` Sébastien Vauban
2011-02-22  0:39       ` Filippo A. Salustri
2011-02-22  4:59         ` Richard Lawrence [this message]
2011-02-22  9:19           ` Carsten Dominik
2011-02-22 16:06             ` Richard Lawrence
2011-02-22  7:43         ` Nick Dokos
2011-02-22  9:15         ` Carsten Dominik
2011-02-22 11:37           ` Bastien
2011-02-23 14:49           ` Filippo A. Salustri
2011-02-23 17:28           ` Filippo A. Salustri
2011-02-21 15:32 ` Matthew Sauer
2011-02-21 16:01 ` Matthew Sauer

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=87r5b0d5qu.fsf@berkeley.edu \
    --to=richard.lawrence@berkeley.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

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).