bug#30800: 26.0.91; unknown crash on macos

[Aaron Jensen <aaronjensen@gmail.com>]

On Thu, Mar 22, 2018 at 12:26 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> I do not understand why setting the represented filename where it was
>> set originally causes a flicker.
>
> I don't understand, either, especially since I don't see this on w32.
>
> The recipes in bug#18757 seem to indicate that redisplaying the
> frame's title, due to the change in the selected buffer, causes the
> flickering.  That flickering started happening with the upgrade to
> version 10.10 of the OS, so perhaps it's no linger an issue with the
> current OS versions?
>
>> It's probably a dumb question, but would using the start/stop paint
>> stuff from the flicker bug help to eliminate the flicker in some way?
>
> Do you still see the flicker if you revert the above commit?

I do not on 10.13.2 when I follow the steps outlined in the original report.

I don't know what's going on in the code exactly, but would it be
worth it to risk the flicker on older macOS (or people's setups that
can repro it if mine just can't) in order to ensure that the
represented filename gets set on a frame that is about to be freed? Or
maybe there's something more that's going on here that I don't
understand.

By the way, flycheck-posframe changed it so that they hide the frame
(and eventually reuse it) instead of killing it after it is used,
which should make this crash less likely in the future for others. I
still think it should be patched, but that's some good news.

Related to that, the more consistent repro for this is to use
flycheck-posframe and move the point to and from an error, which
causes the a new frame to flicker in and out of existence. It's
probably possible to script this to an even more concise repro.