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

Previous Next

To reply to this bug, email your comments to 67694 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; tool-bar
Date: Thu, 7 Dec 2023 16:44:15 +0100

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.

Koinrad

Message #8 received at 67694 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
Cc: 67694 <at> debbugs.gnu.org
Subject: Re: bug#67694: 30.0.50; tool-bar
Date: Sat, 16 Dec 2023 14:15:05 +0100

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.

Message #11 received at 67694 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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

Message #14 received at 67694 <at> debbugs.gnu.org (full text, mbox):

From: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
To: Alan Third <alan <at> idiocy.org>
Cc: 67694 <at> debbugs.gnu.org, Daniel Martín <mardani29 <at> yahoo.es>
Subject: Re: bug#67694: 30.0.50; tool-bar
Date: Mon, 18 Dec 2023 17:44:11 +0100

> 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 did not help me.

Konrad

Message #17 received at 67694 <at> debbugs.gnu.org (full text, mbox):

From: Konrad Podczeck <konrad.podczeck <at> univie.ac.at>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 67694 <at> debbugs.gnu.org
Subject: Re: bug#67694: 30.0.50; tool-bar
Date: Mon, 18 Dec 2023 17:48:31 +0100

> Could you describe the steps to reproduce this bug in more detail?  Does
> it happen only when using the pdf-tools package?


No idea.

> 
> 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 have inserted something like the following in pdf-view.el:


(defvar pdfview-tool-bar-map
  (let ((map (make-sparse-keymap)))
(tool-bar-local-item "some-picture-name-1" 'pdf-view-first-page 'pdf-view-first-page map :help "First page")
(tool-bar-local-item "some-picture-name-2" 'pdf-view-next-page 'pdf-view-next-page map :help "Next page")
(tool-bar-local-item "some-picture-name-3" 'pdf-view-previous-page 'pdf-view-previous-page map :help "Previous page")
(tool-bar-local-item "some-picture-name-4" 'pdf-view-last-page 'pdf-view-last-page map :help "Last page")
map)



and, after the block starting with "(setq-local mode-line-position


(setq-local tool-bar-map pdfview-tool-bar-map)

Konrad

Previous Next

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