I can no longer reproduce any issues with setting the frame-default-alist,
so this patch removes the timer workaround. I'm using macOS 15.1, no idea
if that's relevant or not.


Aaron


On Wed, Sep 13, 2017 at 1:13 PM, Alan Third <alan@idiocy.org> wrote:

> On Wed, Sep 13, 2017 at 12:33:48PM -0700, Aaron Jensen wrote:
>
> On Wed, Sep 13, 2017 at 12:27 PM, Alan Third <alan@idiocy.org> wrote:
>
> On Wed, Sep 13, 2017 at 05:15:49AM -0700, Aaron Jensen wrote:
>
> When ns-use-native-fullscreen is nil and a frame is set to fullscreen,
> there is a slight pause before the frame goes fullscreen. I believe the
> pause is about the same length as the animation when native fullscreen is
> used, so I'm wondering if there's some timing code in there that can be
> disabled when non-native fullscreen is being used.
>
> Found it. In ns_fullscreen_hook in nsterm.m there is a timer:
>
> /* Old style fs don't initiate correctly if created from
> init/default-frame alist, so use a timer (not nice...).
> */
> [NSTimer scheduledTimerWithTimeInterval: 0.5 target: view selector:
> @selector (handleFS)
> userInfo: nil repeats: NO];
>
> if I replace the timer with
>
> [view handleFS]
>
> it works absolutely fine, but I have to assume there are situations where
> it doesn’t.
>
> My guess is that the timer was there to sync w/ the animation. If the
> animation is disabled, there shouldn't be a timer, but if it is, there
> should be. This is just a guess.
>
> I should have read it a bit more closely. The comment’s saying there’s a
> problem when
>
> (add-to-list ’frame-default-alist ’(fullscreen . fullboth))
>
> is used, and sure enough, when I set it and create a new frame, it draws
> incorrectly.
>
> I notice that changing back from fullscreen results in the top of the
> emacs window being hidden behind the toolbar. Clearly non‐native fullscreen
> has some resizing issues.
>
> It can be (correctly) emulated with:
>
> (set-frame-parameter nil 'undecorated t)
> (setq ns-auto-hide-menu-bar 1)
> (tool-bar-mode -1)
> (toggle-frame-maximized)
>
> which makes me wonder if we even need this code and could move it to lisp?
> --
> Alan Third
>