From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Abrahamsen Subject: Re: org-open-link-from-string in a program Date: Sat, 03 Aug 2013 18:26:39 +0800 Message-ID: <87mwoz3w9s.fsf@ericabrahamsen.net> References: <87ehab5fgr.fsf@ericabrahamsen.net> <87mwoz16ba.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:36017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Z2T-0005HT-6v for emacs-orgmode@gnu.org; Sat, 03 Aug 2013 06:26:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V5Z2N-00020F-2t for emacs-orgmode@gnu.org; Sat, 03 Aug 2013 06:26:21 -0400 Received: from plane.gmane.org ([80.91.229.3]:52562) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V5Z2M-000202-St for emacs-orgmode@gnu.org; Sat, 03 Aug 2013 06:26:15 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1V5Z2L-00047V-Nt for emacs-orgmode@gnu.org; Sat, 03 Aug 2013 12:26:13 +0200 Received: from 221.216.167.20 ([221.216.167.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Aug 2013 12:26:13 +0200 Received: from eric by 221.216.167.20 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 03 Aug 2013 12:26:13 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Thorsten Jolitz writes: > Eric Abrahamsen 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.