emacs-devel
[Top][All Lists]
Advanced

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

Re: address@hidden: Re: redisplay]


From: YAMAMOTO Mitsuharu
Subject: Re: address@hidden: Re: redisplay]
Date: Mon, 16 Mar 2009 10:37:19 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

[Revisiting an old change]

>>>>> On Wed, 25 Apr 2007 20:30:08 +0200, Jan Djärv <address@hidden> said:

> After some experimenting it seems that this patch fixes it.  Note
> that a call to redisplay() does not fix the bug.  I don't know why.
> But a full redisplay before every dialog maybe is too much?

> diff -w -c src/xmenu.c.~1.317.~ src/xmenu.c
> Index: src/xmenu.c
> *** src/xmenu.c.~1.317.~        2007-01-21 11:33:57.000000000 +0100
> --- src/xmenu.c 2007-04-25 20:27:02.000000000 +0200
> ***************
> *** 3333,3338 ****
> --- 3333,3340 ----
>      /* No selection has been chosen yet.  */
>      menu_item_selection = 0;

> +   Fredisplay (Qt);
> +
>      /* Actually create and show the dialog.  */
>      create_and_show_dialog (f, first_wv);

Fredisplay runs timers and may cause string data relocation by GC.
Just before the call to Fredisplay, a widget value is created and it
points to some string data, which are to be used as button labels
after the Fredisplay call.  So this may cause corruption of dialog
button labels.  I've never seen such corruption actually, but I think
that may happen in principle unless I'm missing something.

                                     YAMAMOTO Mitsuharu
                                address@hidden




reply via email to

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