Re: [O] org-open-link-from-string in a program
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. > > 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 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!
Re: [O] org-open-link-from-string in a program
Eric Abrahamsen writes: > Thorsten Jolitz writes: > >> Eric Abrahamsen writes: >> >>> Thorsten Jolitz writes: >>> Eric Abrahamsen 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
Thorsten Jolitz writes: > Eric Abrahamsen writes: > >> 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. > > [...] > >>> #+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 writes: > 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. [...] >> #+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 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.
Re: [O] org-open-link-from-string in a program
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? Anyway, when you're done - please share, this is quite interesting. -- cheers, Thorsten
