GNU bug report logs - #22214
25.0.50; lock up with gui dialogs and clipmon-mode

Previous Next

Full log

View this message in rfc822 format

From: Brian Burns <bburns.km <at> gmail.com>
To: Joseph Mingrone <jrm <at> ftfl.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 22214 <at> debbugs.gnu.org
Subject: bug#22214: 25.0.50; lock up with gui dialogs and clipmon-mode
Date: Thu, 24 Dec 2015 01:43:39 -0600

[Message part 1 (text/plain, inline)]

Joseph Mingrone <jrm <at> ftfl.ca> wrote:

> Here is the simplest example I can come up with that causes the problem.
>
> ;; substitute x-get-selection-value for 24.x
> (run-at-time nil 2 (gui-get-primary-selection))
> (menu-set-font)
>

Thanks, that does it - I tried adding menu-or-popup-active-p around it but
it didn't help -

(defun foo ()
  (if (not (menu-or-popup-active-p))
    (x-get-selection-value)))

(run-at-time nil 2 'foo)
(menu-set-font)

Maybe there's some other way to tell if a gui window is showing / waiting
for input? Then as a workaround I could just skip checking the clipboard.

I looked at some of the internals - as Eli said there's an event loop for
the x dialog that also checks the existing Emacs timers, which in this case
would be checking the x selection and starting another timer.

I'm not sure why that would cause a hang though, if the x selection returns
immediately.

Thanks again for your help in tracking this down - I'll keep tracing
through the code to see if I can figure out what's going on, and why
menu-or-popup-active-p doesn't help.

Brian

[Message part 2 (text/html, inline)]

Previous Next

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