GNU bug report logs - #67694
30.0.50; tool-bar

Previous Next

Package: emacs;

Reported by: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>

Date: Thu, 7 Dec 2023 15:45:01 UTC

Severity: normal

Merged with 51336, 67528

Found in versions 29.0.50, 30.0.50

Full log


View this message in rfc822 format

From: Alan Third <alan <at> idiocy.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>, 67694 <at> debbugs.gnu.org
Subject: bug#67694: 30.0.50; tool-bar
Date: Sat, 16 Dec 2023 20:13:12 +0000
On Sat, Dec 16, 2023 at 02:15:05PM +0100, Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
> Konrad Podczeck <konrad.podczeck <at> univie.ac.at> writes:
> 
> > In nsterm.m, deleting the lines of code
> >
> >
> > #ifdef NS_IMPL_COCOA
> > if (! send_appdefined)
> >   {
> >   /* OS X 10.10.1 swallows the AppDefined event we are sending ourselves
> >        in certain situations (rapid incoming events).
> >        So check if we have one, if not add one.  */
> >     NSEvent *appev = [NSApp nextEventMatchingMask:NSEventMaskApplicationDefined
> >                                         untilDate:[NSDate distantPast]
> >                                            inMode:NSDefaultRunLoopMode
> >                                           dequeue:NO];
> >     if (! appev) send_appdefined = YES;
> >   }
> > #endif
> >
> > as done in commit 6acb3c5b05a7b9fb32a5336e1bb740f527571ae9 on
> > 23-09-11, seems to be incompatible with macos Sonoma or Monterey. In
> > both versions, and with both an M1 processor and an Intel one, I got
> > the following problem, with these lines of code removed. I have
> > pdf-tools installed, and via the code in windows.el, I have both the
> > pdf output and some latex source code to appear in their own frames. I
> > also have a managed to have a tool-bar in the frame showing the
> > pdf-outout, with an icon for going from one page to the next. Now if I
> > repeatedly click with the mouse on this icon very fast, then, after 3
> > to 5 clicks, the whole emacs.app begins to hang. This is not so with
> > the above lines of code still present in nsterm.m.
> 
> Could you describe the steps to reproduce this bug in more detail?  Does
> it happen only when using the pdf-tools package?
> 
> Starting from emacs -Q, I’ve installed the pdf-tools package (M-x
> package-install RET pdf-tools RET), but, after visiting a PDF file, I
> don’t see any tool-bar icons to go to the previous and next page in the
> PDF.

I hate this application defined event malarkey, but I was never able
to come up with a better solution. The problem described in the
removed comment certainly looks like an Apple bug, but if it is then
surely it would have been fixed by now.

Konrad, are you able to try changing the code thus (the line numbers
are probably wrong):

modified   src/nsterm.m
@@ -4604,10 +4604,16 @@ Function modeled after x_draw_glyph_string_box ().
                                    data1: value
                                    data2: 0];
 
-      /* Post an application defined event on the event queue.  When this is
-         received the [NXApp run] will return, thus having processed all
-         events which are currently queued.  */
-      [NSApp postEvent: nxev atStart: NO];
+      if (! nxev)
+        {
+          NSLog(@"Something has stopped us creating an event.");
+          send_appdefined = YES;
+        }
+      else
+        /* Post an application defined event on the event queue.  When this is
+           received the [NXApp run] will return, thus having processed all
+           events which are currently queued.  */
+        [NSApp postEvent: nxev atStart: NO];
     }
 }

See if the log message prints, and/or whether it solves the problem.

-- 
Alan Third




This bug report was last modified 1 year and 5 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.