[bug] org-insert-link in different frame

[bug] org-insert-link in different frame

[Lluís]

I tried to insert a previously stored link in an org-mode buffer that was in a
`framepop' buffer (framepop "pins" a buffer in a separate frame, and all
interactions are redirected to the non-framepop frame).

The result is that '(get-buffer-window "*Org Links*")' returns 'nil' and thus
the function throws an exception.

This could be easily fixed by using the second argument FRAME in
`get-buffer-window'. In any case, which would be the best value for that
argument still escapes my knowledge (I supose `t' would be safe and work in all
cases).

I'm using version 6.34c.


In an unrelated note, I'm using an approach similar to that of

   http://tsdh.wordpress.com/2009/03/

and when saving an org-mode file in the framepop frame, the hook is somehow
unable to prevent the excursion, thus showing me the agenda buffer on my main
working frame.

I tried a `framepop-toggle-frame' before and after the `save-excursion' code if
`selected-frame' is `framepop-frame' (which should get back to the "working"
frame and thus save excursions in there). Even if the framepop-frame is visibly
toggled, it still shows the same undesired behaviour.

Thanks,
        Lluis

--
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

Re: [bug] org-insert-link in different frame

[Carsten Dominik]

Hi Lluis, would you like to make a patch for me to fix this?

- Carsten

On Mar 30, 2010, at 7:17 PM, Lluís wrote:

> I tried to insert a previously stored link in an org-mode buffer  
> that was in a
> `framepop' buffer (framepop "pins" a buffer in a separate frame, and  
> all
> interactions are redirected to the non-framepop frame).
>
> The result is that '(get-buffer-window "*Org Links*")' returns 'nil'  
> and thus
> the function throws an exception.
>
> This could be easily fixed by using the second argument FRAME in
> `get-buffer-window'. In any case, which would be the best value for  
> that
> argument still escapes my knowledge (I supose `t' would be safe and  
> work in all
> cases).
>
> I'm using version 6.34c.
>
>
> In an unrelated note, I'm using an approach similar to that of
>
>   http://tsdh.wordpress.com/2009/03/
>
> and when saving an org-mode file in the framepop frame, the hook is  
> somehow
> unable to prevent the excursion, thus showing me the agenda buffer  
> on my main
> working frame.
>
> I tried a `framepop-toggle-frame' before and after the `save- 
> excursion' code if
> `selected-frame' is `framepop-frame' (which should get back to the  
> "working"
> frame and thus save excursions in there). Even if the framepop-frame  
> is visibly
> toggled, it still shows the same undesired behaviour.
>
> Thanks,
>        Lluis
>
> --
> "And it's much the same thing with knowledge, for whenever you learn
> something new, the whole world becomes that much richer."
> -- The Princess of Pure Reason, as told by Norton Juster in The  
> Phantom
> Tollbooth
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

Re: [bug] org-insert-link in different frame

[Lluís]

[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]

> Hi Lluis, would you like to make a patch for me to fix this?

Here it goes.

Note that I've found some weirdness that I don't know how to solve,
and might well be a systemic problem of the current implementation of
`framepop' (or either a lack of elisp knowledge from my part):

   - Bind an org-mode buffer to framepop from "frame0"
     (`framepop-display-buffer'); this creates "framefp" and calls
     `redirect-frame-focus', redirecting "framefp" to "frame0"
   - Create a new frame "frame1".
   - Call `suspend-frame' on "frame0"
   - Switch to "framefp" and call `org-insert-link'

This has the unfortunate effect of showing the "*Org Links*" buffer in
"frame1", and then raising "frame0" for the user input in the
minibuffer.

Result? If both "frame0" and "frame1" were on the same screen, the
former is on top of the latter, thus preventing the useer to see the
"*Org Links*" buffer.

After some tests, I've also found that `get-buffer-window' prefers
"frame1" even when `org-completing-read' later on uses "frame0" for
the minibuffer, so this is still confusing to use (now without having
`suspend-frame' on "frame0").

My elisp knowledge is too limited to find a solution to this, but the
patch at least works in the simple case of "frame0"+"framefp" (which
is the schenario that raised the initial error).


Read you,
     Lluis



[-- Attachment #2: org.el.patch --]
[-- Type: text/plain, Size: 600 bytes --]

--- /usr/share/emacs/site-lisp/org-mode/org.el	2010-03-05 11:28:54.000000000 +0100
+++ /tmp//org.el	2010-04-07 18:11:42.000000000 +0200
@@ -8023,7 +8023,8 @@
 		    (if (nth 1 x) (concat (car x) " (" (nth 1 x) ")") (car x)))
 		  (reverse org-stored-links) "\n"))))
       (let ((cw (selected-window)))
-	(select-window (get-buffer-window "*Org Links*"))
+	;; must also search on other frames in case of using `redirect-frame-focus'
+	(select-window (get-buffer-window "*Org Links*" 'visible))
 	(setq truncate-lines t)
 	(unless (pos-visible-in-window-p (point-max))
 	  (org-fit-window-to-buffer))

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]



--
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth

[-- Attachment #4: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [bug] org-insert-link in different frame

[Carsten Dominik]

Applied, thanks.

- Carsten

On Apr 7, 2010, at 6:16 PM, Lluís wrote:

>> Hi Lluis, would you like to make a patch for me to fix this?
>
> Here it goes.
>
> Note that I've found some weirdness that I don't know how to solve,
> and might well be a systemic problem of the current implementation of
> `framepop' (or either a lack of elisp knowledge from my part):
>
>   - Bind an org-mode buffer to framepop from "frame0"
>     (`framepop-display-buffer'); this creates "framefp" and calls
>     `redirect-frame-focus', redirecting "framefp" to "frame0"
>   - Create a new frame "frame1".
>   - Call `suspend-frame' on "frame0"
>   - Switch to "framefp" and call `org-insert-link'
>
> This has the unfortunate effect of showing the "*Org Links*" buffer in
> "frame1", and then raising "frame0" for the user input in the
> minibuffer.
>
> Result? If both "frame0" and "frame1" were on the same screen, the
> former is on top of the latter, thus preventing the useer to see the
> "*Org Links*" buffer.
>
> After some tests, I've also found that `get-buffer-window' prefers
> "frame1" even when `org-completing-read' later on uses "frame0" for
> the minibuffer, so this is still confusing to use (now without having
> `suspend-frame' on "frame0").
>
> My elisp knowledge is too limited to find a solution to this, but the
> patch at least works in the simple case of "frame0"+"framefp" (which
> is the schenario that raised the initial error).
>
>
> Read you,
>     Lluis
>
>
> <org.el.patch>
>
> --
> "And it's much the same thing with knowledge, for whenever you learn
> something new, the whole world becomes that much richer."
> -- The Princess of Pure Reason, as told by Norton Juster in The  
> Phantom
> Tollbooth

- Carsten