emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Orgmode] Re: Capture template and elisp expression


From: Štěpán Němec
Subject: [Orgmode] Re: Capture template and elisp expression
Date: Fri, 07 Jan 2011 13:08:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Carsten Dominik <address@hidden> writes:

> On Jan 6, 2011, at 11:26 PM, Nick Dokos wrote:
>
>> Rainer M Krug <address@hidden> 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: address@hidden
>>> %(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: address@hidden %![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: address@hidden        %(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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]