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.
Hmm, I tried sticking a (redisplay) after opening the link, thinking that might "reset" what is considered the current buffer, and it still doesn't do it!