bug#25818: 25.2; frame moved off display does not return (OS X)

[Charles A. Roelli]

Hi Anders,

> Also, I'm sure it will work with L-shaped layouts as well,
> even though I haven't tried it.

I gave it a try and it worked as expected.

> I've got two minor comments. And when I say "minor" they really are minor,
> feel free to disregard them if you like:
>
> * The nsterm.m file is (almost) tab free, so I would appreciate if you
> would untabify the code.
>
> * Replace the comment with something like the following:
>
>     // Check that the proposed frame placement is visible in at least
>     // one screen.  If it is not, ask the system to reposition it.
>
> If someone doesn't understand what the code does and why, the original
> comment doesn't help as it only repeats the algorithm of the code. Also, I
> don't see the need to refer to a bug number in the comment, except under
> very special circumstances -- that information is available in the git
> commit message.

Good points, I've made these fixes in the attached patch.

>> Hm... but what if a second display is in the negative coordinate space?
>> How would you place a frame on it programmatically?
>
> You can set the `left' and `top' frame parameters. If they are assigned an
> integer they act like `set-frame-position' is supposed to work. However, if
> they are assigned `(+ INTEGER)' or `(- INTEGER)' the value is specified
> relative to the left (top) or right (bottom) edge of the display,
> respectively. This allows a frame to be placed anywhere.

I see now, thanks for this explanation.  I tried building Emacs with X
(--with-x --with-ns=no) and the configuring step picked up my installed
version of GTK3, then later failed at the linking stage for temacs due
to some GDK-related symbols not being present.  Have you seen similar
errors?

Cheers,
Charles

0001-Constrain-frames-to-visible-area-of-screens-in-OS-X-v2.patch
Description: Text Data