bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#31312: Segmentation fault with doom-emacs, NeoTree and Zoom


From: Eli Zaretskii
Subject: bug#31312: Segmentation fault with doom-emacs, NeoTree and Zoom
Date: Thu, 03 May 2018 05:32:44 +0300

> From: Noam Postavsky <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Wed, 02 May 2018 20:04:28 -0400
> 
> martin rudalics <address@hidden> writes:
> 
> >> So we need the same defense after prepare_menu_bars as we
> >> have after do_pending_changes, I think.
> >
> > If you mean something like
> >
> >   if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
> >     sw = w;
> >
> > I'm afraid that this would fail since selected_window has no buffer
> > any more (or may have even been recycled already).  Or am I missing
> > something?
> 
> It seems to work (I don't know enough about the code to explain why).  I
> applied this patch:
> 
> --- i/src/xdisp.c
> +++ w/src/xdisp.c
> @@ -13936,6 +13936,11 @@ redisplay_internal (void)
>    if (NILP (Vmemory_full))
>      prepare_menu_bars ();
>  
> +  /* prepare_menu_bars may call lisp hooks and hence change the
> +     selected_window.  */
> +  if (WINDOWP (selected_window) && (w = XWINDOW (selected_window)) != sw)
> +    sw = w;
> +
>    reconsider_clip_changes (w);
>  
>    /* In most cases selected window displays current buffer.  */
> 
> And then following the original recipe does not segfault.  There is a
> Lisp error, but I think that's already a bug in zoom and/or doom.

Right.

Please push to the emacs-26 branch, and thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]