Hi Paul,
I think I haven't been following this closely enough, because I don't
understand why an external program is necessary for <>. Can
you just have a variable to hold the files that need searching?
Then use the existing org ID mechanism. The targets would hold org IDs.
I realize it would
Hi Paul,
I have now made a new hook `org-open-link-functions'.
Each function in this hook will be called with the link text as the
single
argument. If the function feels responsible for this link, it should
follow the link and return a non-nil value. If it does not feel
responsible for the l
Nick Dokos writes:
> Can these patches be applied using the standard patch(1) command?
> I tried and I get
>
> $ patch < ~/Mail/inbox/1265
> patch: Only garbage was found in the patch input.
You have to replace `{' with `>' and `}' with `<' in the patch before
applying it.
> If they canno
Paul,
Can these patches be applied using the standard patch(1) command?
I tried and I get
$ patch < ~/Mail/inbox/1265
patch: Only garbage was found in the patch input.
If they cannot be applied that way, can you please provide them in a
more standard format? Unified diff format is probabl
Sorry guys, I seem to be spamming this topic, but I just fixed another problem
-- properties on the link string were causing problems with find-tag, which
expected a propertyless string.
Fixed patch follows.
BEGIN PATCH for org.el (delete this line)
8349,8369c8349,8350
{ (cond
Also I realised there was a misplaced parenthesis in the "(if (y-or-n-p..."
clause. Corrected patch follows.
BEGIN PATCH for org.el (delete this line)
8349,8369c8349,8350
{ (condition-case nil (eval cmd)
{ ;; ORG-TAGS
{ (error
{(progn
Carsten Dominik gmail.com> writes:
>
> Hi Paul,
>
> I like this very much. But I would like to change the implementation
> so that
> there will be a hook. Then people can do different things, including
> matching tags in source code files etc.
>
> Would you be interested to turn your way
