GNU bug report logs -
#50043
28.0.50; USABLE_SIGOI undef code paths do not work correctly
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Fri, 13 Aug 2021 11:57:01 UTC
Severity: normal
Found in version 28.0.50
Done: Ken Brown <kbrown <at> cornell.edu>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 17 Nov 2021 12:45:24 -0500
with message-id <8bdea42d-67bd-d8cd-fa5c-bf9059c11146 <at> cornell.edu>
and subject line Re: bug#50043: 28.0.50; USABLE_SIGOI undef code paths do not work correctly
has caused the debbugs.gnu.org bug report #50043,
regarding 28.0.50; USABLE_SIGOI undef code paths do not work correctly
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
50043: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50043
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
To reproduce the problem on Debian (at least), edit src/config.h to
this:
/* Define to 1 if SIGIO is usable. */
/* #define USABLE_SIGIO 0 */
Then recompile Emacs and say
(let ((value 'SECONDARY)
(x-selection-timeout 2000))
;;; from org-get-x-clipboard in lisp/org-compat.el
(gui-get-selection value 'UTF8_STRING)
(gui-get-selection value 'COMPOUND_TEXT)
(gui-get-selection value 'STRING)
(gui-get-selection value 'TEXT))
This will hang for two seconds instead of returning immediately if
USABLE_SIGIO is defined.
Now, we have SIGIO on almost all supported platforms. The only ones
that have it disabled might be these ones:
hpux* | nacl | solaris | unixware )
emacs_broken_SIGIO=yes
Which is probably why this hasn't been reported more. (See bug#29170.)
So this isn't exactly a high impact problem, but it should be fixed
anyway.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
[Message part 3 (message/rfc822, inline)]
On 11/17/2021 12:37 PM, Eli Zaretskii wrote:
>> Date: Wed, 17 Nov 2021 12:25:38 -0500
>> Cc: larsi <at> gnus.org, 50043 <at> debbugs.gnu.org
>> From: Ken Brown <kbrown <at> cornell.edu>
>>
>> There's still one more issue related to this bug, which I mentioned earlier: If
>> x_selection_timeout is zero, x_get_foreign_selection will call
>> wait_reading_process output with an infinite timeout rather than a zero timeout,
>> which I'm sure is not what was intended. The attached patch fixes that.
>
> Bu that's clearly what was intended. The doc string of
> x-selection-timeout says:
>
> A value of 0 means wait as long as necessary.
Oh, I somehow missed that, sorry. In that case I'm closing the bug.
Ken
This bug report was last modified 3 years and 246 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.