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

[Carsten Dominik <carsten.dominik@gmail.com>]

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