Re: org-open-link-from-string in a program

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I'm trying to write a small function that programmatically follows a
>> link to a gnus message, then calls
>> `gnus-summary-wide-reply-with-original' to start a reply to that
>> message. It seemed like `org-open-link-from-string' (after extracting
>> the address part from the link) would be the right choice, but I'm
>> seeing odd behavior.
>>
>> When gnus sets up the reply buffer it also adds several hooks and
>> actions for restoring windows and marking messages as responded-to, etc,
>> and these hooks and actions depend on the value of (current-buffer) when
>> the reply was initiated. That's supposed to be the gnus summary buffer.
>>
>> When I call all this from a function, however, (current-buffer)
>> continues to return the org buffer I started in, even after the link was
>> opened, which confuses gnus, and me. What I mean is this:
>>
>> (let ((addr the-address-part-of-the-link))
>>    (org-open-link-from-string addr)
>>    (message "%s" (current-buffer)) ; returns the org buffer I started in
>>    (call-interactively
>>      'gnus-summary-wide-reply-with-original))
>>
>> There must be something I'm misunderstanding about how buffers work when
>> you're doing something non-interactive. If I manually eval the
>> org-open-link-from-string statement, I end up in the summary buffer,
>> obviously, and all works fine.
>
> #+begin_src emacs-lisp
> (defun org-open-link-from-string (s &optional arg reference-buffer)
>   "Open a link in the string S, as if it was in Org-mode."
>       [...snip...]
> 	(org-open-at-point arg reference-buffer)))))
> #+end_src
>
> ,----------------------------------------------------------------------
> | org-open-at-point is an interactive Lisp function in `org.el'.
> |
> | (org-open-at-point &optional ARG REFERENCE-BUFFER)
> |
> | Open link at or after point.
> | If there is no link at point, this function will search forward up to
> | the end of the current line.
> | Normally, files will be opened by an appropriate application.  If the
> | optional prefix argument ARG is non-nil, Emacs will visit the file.
> | With a double prefix argument, try to open outside of Emacs, in the
> | application the system uses for this file type.
> `----------------------------------------------------------------------
>
> Maybe because you call
>
> ,---------------------------------
> | (org-open-link-from-string addr)
> `---------------------------------
>
> without ARG, Emacs is not visiting the file and thus its buffer does not
> become current?

Huh, interesting -- I had looked at that function, and assumed that the
what the arg did was to force a file that might otherwise be opened by
an external process to be opened in emacs. I still think that's what it
means (and adding a '(4) doesn't solve the problem), but there's other
stuff in there that might lead to a solution.

> Anyway, when you're done - please share, this is quite interesting.

I will! It's pretty much done, except for this one little bug.