bug#12834: 24.3.50; OS X selecting a font can lock Emacs

[Ivan Andrus]

Well it went from being 100% reproducible to only about 10%.  Although I 
haven't tested it exhaustively, it seems to only be a problem when I type in 
some ridiculously large font size e.g. 7000.  So I think it's probably not 
really an issue.

-Ivan

On Nov 17, 2012, at 4:29 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Hello.
> 
> I can reproduce it sometimes, but not most of the times.  Anyway, I made 
> another checkin in the emacs-24 branch.  Please try it.
> 
>       Jan D.
> 
> 14 nov 2012 kl. 10:39 skrev Ivan Andrus <darthandrus@gmail.com>:
> 
>> On Nov 14, 2012, at 7:08 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>> 
>>> Hello.
>>> 
>>> 13 nov 2012 kl. 19:40 skrev Ivan Andrus <darthandrus@gmail.com>:
>>> On Nov 13, 2012, at 4:19 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>>>>> Which version did you build? Are you sure you built the emacs-24 branch, 
>>>>> not trunk?
>>>> 
>>>> To be honest I'm not entirely sure how to figure that out.  Every time I 
>>>> think I understand bzr it doesn't do what I think.  Anyway, updating on 
>>>> the branch I get
>>>> 
>>>> $ bzr pull
>>>> Using saved parent location: bzr://bzr.savannah.gnu.org/emacs/emacs-24/    
>>>>                                                                            
>>>>                               
>>>> No revisions or tags to pull.                                              
>>>>                                                                            
>>>>                               
>>>> 
>>>> In src/nsterm.m I see
>>>> 
>>>> 303  static void
>>>> 304  hold_event (struct input_event *event)
>>>> 305  {
>>>> 306    if (hold_event_q.nr == hold_event_q.cap)
>>>> 307      {
>>>> 308        if (hold_event_q.cap == 0) hold_event_q.cap = 10;
>>>> 309        else hold_event_q.cap *= 2;
>>>> 310        hold_event_q.q = (struct input_event *)
>>>> 311          xrealloc (hold_event_q.q, hold_event_q.cap * sizeof 
>>>> (*hold_event_q.q));
>>>> 312      }
>>>> 313  
>>>> 314    hold_event_q.q[hold_event_q.nr++] = *event;
>>>> 315    /* Make sure ns_read_socket is called, i.e. we have input.  */
>>>> 316    kill (0, SIGIO);
>>>> 317  }
>>>> 
>>>> which I think is the required change.  I still see the problem.  When I 
>>>> run under gdb I am unable to interrupt the process with Ctrl-C once it has 
>>>> stopped responding.  I'm afraid I'm not sure how to help debug it 
>>>> otherwise.  Sending SIGIO manually doesn't cause it to become responsive.
>>> 
>>> That is the fix.  Sending SIGIO manually is pointless.  I can not reproduce 
>>> the error anymore, so make sure you did make install, and give the exact 
>>> steps you did to encounter the bug, starting from -Q.
>> 
>> I ran make install to be sure.
>> 
>> ./nextstep/Emacs.app/Contents/MacOS/Emacs -Q
>> 
>> Interestingly this opens ~/.emacs.d/abbref_defs which had an error on my 
>> machine.  Is this expected with -Q?  Anyway, it's probably not relevant to 
>> the discussion at hand since I see the same behaviour if I move .emacs.d 
>> entirely.
>> 
>> Then I run `menu-set-font', either from the menu or with C-x C-e.  I can 
>> change the font and the size freely.  Then I click in the "Size" text box.  
>> A few times this hasn't caused problems, but usually it causes Emacs to stop 
>> responding.  The font panel still responds, but nothing changes in terms of 
>> the font displayed and it doesn't register typing etc.  FWIW, I added a 
>> printf to hold_event and it gets called 3 times when I click on anything 
>> other than the text box, but only twice when I click on the text box. 
>> 
>> Thanks for looking into this.  I'm running 10.8.2 with home brew installed 
>> with the latest XCode installed.  I recently upgraded from 10.6.8.  I'm not 
>> sure what else might be at play.
>> 
>> -Ivan
>