Re: [O] org-open-link-from-string in a program
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. What am I not getting? Thanks! Eric I think I've got it: when `org-open-link-from-string' calls `org-open-at-point', it passes the current buffer as an argument. `org-open-at-point' then wraps the call to `org-link-protocols' (specifically `org-gnus-open' in this case) in a `with-current-buffer' that uses that original buffer. To be honest I'm not really sure if that's the problem -- once `org-open-link-from-string' returns, I would think that interior `with-current-buffer' had passed out of scope. Gnus sets up the reply buffer after open-link-from-string has returned, by which point I would think it could get new values of `current-buffer'. Anyway, it works to replace `org-open-link-from-string' with: (org-gnus-open (org-link-unescape link-address)) So that's what I'll do! Once I've made sure I haven't broken these functions while messing with them, I'll post code here. Eric
Re: [O] org-open-link-from-string in a program
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? Anyway, when you're done - please share, this is quite interesting. -- cheers, Thorsten
Re: [O] org-open-link-from-string in a program
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.
Re: [O] org-open-link-from-string in a program
Eric Abrahamsen e...@ericabrahamsen.net writes: 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. [...] #+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. Yes, you are right about the meaning of ARG, I should have looked twice. Anyway, when you're done - please share, this is quite interesting. I will! It's pretty much done, except for this one little bug. I can imagine that this is very useful for managing phonecalls to be made in the future... -- cheers, Thorsten
Re: [O] org-open-link-from-string in a program
Thorsten Jolitz tjol...@gmail.com writes: Eric Abrahamsen e...@ericabrahamsen.net writes: 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. [...] #+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. Yes, you are right about the meaning of ARG, I should have looked twice. Anyway, when you're done - please share, this is quite interesting. I will! It's pretty much done, except for this one little bug. I can imagine that this is very useful for managing phonecalls to be made in the future... Well this will only cover composing and replying to emails, but if you have a function that automatically makes a phone call, I suppose it would serve as a template... Mostly I'm doing it because a full half of my work seems to be replying to interminable emails, and I wanted something that would keep me in the agenda as much as possible: hit a key on a TODO, type the email, send it, and there you are back in the agenda again. It's turning out to be a little more complicated than I thought!
Re: [O] org-open-link-from-string in a program
Eric Abrahamsen e...@ericabrahamsen.net writes: Thorsten Jolitz tjol...@gmail.com writes: Eric Abrahamsen e...@ericabrahamsen.net writes: Thorsten Jolitz tjol...@gmail.com writes: Eric Abrahamsen e...@ericabrahamsen.net writes: I can imagine that this is very useful for managing phonecalls to be made in the future... Well this will only cover composing and replying to emails, but if you have a function that automatically makes a phone call, I suppose it would serve as a template... did I write phonecalls? I meant emails, obviously, and I stop posting for today and go out for walk ... ;) Mostly I'm doing it because a full half of my work seems to be replying to interminable emails, and I wanted something that would keep me in the agenda as much as possible: hit a key on a TODO, type the email, send it, and there you are back in the agenda again. It's turning out to be a little more complicated than I thought! thats more of less what I imagined, and it definitely sounds useful. -- cheers, Thorsten
Re: [O] org-open-link-from-string in a program
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!
