From: "Štěpán Němec" <stepnem@gmail.com>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: nicholas.dokos@hp.com, emacs-orgmode <emacs-orgmode@gnu.org>,
Rainer M Krug <r.m.krug@gmail.com>
Subject: Re: Capture template and elisp expression
Date: Fri, 07 Jan 2011 13:08:04 +0100 [thread overview]
Message-ID: <87mxnc6hnf.fsf@gmail.com> (raw)
In-Reply-To: <FBA98CDC-6138-4EF2-B9F5-57F01A31620A@gmail.com> (Carsten Dominik's message of "Thu, 6 Jan 2011 23:44:56 +0100")
Carsten Dominik <carsten.dominik@gmail.com> writes:
> On Jan 6, 2011, at 11:26 PM, Nick Dokos wrote:
>
>> Rainer M Krug <r.m.krug@gmail.com> wrote:
>>
>>>
>>> Hi
>>>
>>> I want to use a Capture Template to record changes to files under
>>> version control. Everything works as expected, but I would like to
>>> include the current revision in the template.
>>>
>>> Therefore I tried the following:
>>>
>>> * %T %? at %a by Rainer M Krug, email: Rainer@krugs.de
>>> %(vc-working-revision buffer-file-name)
>>>
>>> for the template, but I get an error:
>>>
>>> **** <2011-01-06 Thu 13:06> at
>>> [[file:~/Documents/Projects/BiocontrolAndAlienDynamics/
>>> nonSpatialAcacia/trunc/R/nsa.org::*Finalise][Finalise]]
>>> by Rainer M Krug, email: Rainer@krugs.de %![Error: (wrong-type-
>>> argument
>>> stringp nil)]
>>>
>>> Any idea how I could get the revision of the org file from which the
>>> Capture has been initiated (here
>>> ~/Documents/Projects/BiocontrolAndAlienDynamics/nonSpatialAcacia/
>>> trunc/R/nsa.org
>>> )?
>>>
>>
>> There are a few problems: the evaluation of the sexp happens in the
>> capture buffer where buffer-file-name returns nil. Even if you could
>> get the file name, vc-working-revision would return nil on a file that
>> is not VC-registered and the template would barf.
>>
>> Those are easy problems to solve but there is another one that seems
>> insurmountable (with current code): my original thought was to use the
>> %a escape to pass the link to a lisp function, extract the file name
>> from it[fn:1] and run vc-working-revision on it (with appropriate safeguards
>> to catch non-VC files), something like this:
>>
>> "* %T %? at %a by Rainer M Krug, email: Rainer@krugs.de %(rk-
>> custom-function-to-get-vc-revision \"%a\")"
>>
>> However, this fails because at the time that %(sexp) constructs are
>> expanded, simple %a etc. constructs have not been expanded yet, so what
>> the function above gets is a literal "%a": the subtitution sequence is
>>
>> ;; %[] Insert contents of a file.
>>
>> ...
>>
>> ;; %() embedded elisp
>>
>> ...
>>
>> ;; Simple %-escapes
>>
>> (see lisp/org-capture.el, lines 1181-1229 or so).
>>
>> Moreover, this sequence was different and was changed deliberately (see
>> the thread http://thread.gmane.org/gmane.emacs.orgmode/27649), so if it
>> is changed back, Sebastion Rose will not be happy :-)
>>
>> So it seems there is no way to pass values from the capture context to a
>> lisp function in the capture template, but maybe I'm missing something.
>>
>> Thanks,
>> Nick
>>
>> Footnotes:
>> [fn:1] Is there an easier way to get the filename of the file I was
>> visiting when I initiated the capture? If not, should there be? Perhaps
>> a %f escape?
>
> Hi Nick,
>
> you can use
>
> (buffer-file-name (org-capture-get :original-buffer))
>
> and we could certainly introduce a special escape for it if helpful.
>
> If it is easier, we can also put the filename itself into the property list,
> and any other information we like. This should happen in the function
> org-capture,
> close to the location where the buffer is stored, so near this line:
>
> (org-capture-put :original-buffer orig-buf :annotation annotation
> :initial initial)
>
> org-capture uses this property list precisely so that it is simple
> to add any information required.
>
> Note that, after the template has been filled in, it is better
> to access information in the property list with
>
>
> (org-capture-get PROPERTY 'local)
>
> to avoid conflicts with other ongoing capture processes.
>
> Hope this helps.
Why aren't the %() expressions simply evaluated in the original buffer
(if available)? That would solve these issues in a general way. It seems
to me that there is no advantage to evaluating the expressions in the
temporary capture buffer, but I'm not familiar with the code so I might
be missing something. Is there a reason for that?
Štěpán
next prev parent reply other threads:[~2011-01-07 12:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-06 12:08 Capture template and elisp expression Rainer M Krug
2011-01-06 22:26 ` Nick Dokos
2011-01-06 22:44 ` Carsten Dominik
2011-01-06 23:41 ` Nick Dokos
2011-01-07 8:22 ` Rainer M Krug
2011-01-07 14:03 ` Nick Dokos
2011-01-07 14:31 ` Rainer M Krug
2011-01-07 12:08 ` Štěpán Němec [this message]
2011-01-07 14:14 ` Carsten Dominik
2011-01-07 14:28 ` Rainer M Krug
2011-01-07 15:00 ` Štěpán Němec
2011-01-08 17:58 ` Carsten Dominik
2011-01-08 18:07 ` Štěpán Němec
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=87mxnc6hnf.fsf@gmail.com \
--to=stepnem@gmail.com \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=nicholas.dokos@hp.com \
--cc=r.m.krug@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).