Thorsten Jolitz <tjol...@gmail.com> writes: > Eric Abrahamsen <e...@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.