GNU bug report logs - #46935
28.0.50; Annoying interactions with X clipboard

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46935 in the body.
You can then email your comments to 46935 AT debbugs.gnu.org in the normal way.

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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Annoying interactions with X clipboard
Date: Fri, 05 Mar 2021 00:28:41 +0100

Hello,

I'm using Emacs under the X window system (Debian with Openbox window
manager).  I'm experiencing the following issues with my setup:

(1) When some other program is very busy or frozen - that can be a
browser executing javascript code, or a program that has crashed or is
frozen, or (this recipe works only sometimes) another Emacs that I have
sent a SIGSTOP, then, when I try to copy or kill text in any buffer,
Emacs also freezes.  Seems to infloop.  C-g always helps, but any other
trial results in freeze again.

In this situation it is impossible to work with Emacs in a useful way.
I have to close or kill the other program, or wait until it is not that
busy any more, to be able to continue working in Emacs.


(2) There are so called "clipboard manager" for X, "parcellite" for
example.  Whenever I tried to use such a program, it has a side effect
on Emacs: Emacs seems to recive some sort of interrupt event or whatever
- this is my interpretation - the visible effect is that some things
stop working, are interrupted, most of the time, this is Helm: instead
of getting a window with completions, I get an empty window.  Repeated
retrying always works sooner or later.  I think, but I am not totally
sure, that I also saw the issue in other situations.  Could likely be
that it is `while-no-input' that gets interrupted.  The effect is
annoying enough that it is not possible to work with Emacs for a longer
time and a started parcellite.  AFAIR this happened with other (all)
clipboard managers I had tried in the past.

Please tell me if you need information about my config.  Some related
setting might be

  select-enable-primary -> t
  select-enable-clipboard -> t
  save-interprogram-paste-before-kill -> t

What would be the shortest way to find the cause?  I also wonder if only
I am seeing this, or whether others only hesitate to report the problem
(would be nice if they could raise their hands now...)


TIA,

Michael.


In GNU Emacs 28.0.50 (build 9, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-03-04 built on drachen
Repository revision: fa74c6c89d67226b31d10bdef66e88cc484b20ea
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SOUND
THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_COLLATE: C
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Fri, 05 Mar 2021 14:46:18 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> (1) When some other program is very busy or frozen - that can be a
> browser executing javascript code, or a program that has crashed or is
> frozen, or (this recipe works only sometimes) another Emacs that I have
> sent a SIGSTOP, then, when I try to copy or kill text in any buffer,
> Emacs also freezes.  Seems to infloop.  C-g always helps, but any other
> trial results in freeze again.

I see the same with "emacs -Q" when I start one emacs, choose text with
the mouse, C-z it, and then start another one and try to paste (with the
mouse).

But I see exactly the same if I try to paste into Firefox, so perhaps
this is just how this stuff is supposed to work?  (That is, Firefox
times out after a few seconds, so it doesn't hang indefinitely.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Thierry Volpiatto <thievol <at> posteo.net>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Fri, 05 Mar 2021 23:43:08 +0100

Thierry Volpiatto <thievol <at> posteo.net> writes:

> > What would be the shortest way to find the cause?
>
> Starting from emacs-27, subr.el is loaded in a way that
> `while-no-input-ignore-events` is not set, so it default to nil.
> IOW the block in subr.el:
>
>     (setq while-no-input-ignore-events
>           '(focus-in focus-out help-echo iconify-frame
>             make-frame-visible selection-request))
>
> is not evaled, it is in emacs-26.3.

Ah, very valuable information.  Yes, the binding is nil for me.

Do you (or anybody) know why this setting doesn't have an effect any
more and what has to be done to fix this?

Thanks,

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Fri, 05 Mar 2021 23:48:42 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> But I see exactly the same if I try to paste into Firefox, so perhaps
> this is just how this stuff is supposed to work?  (That is, Firefox
> times out after a few seconds, so it doesn't hang indefinitely.)

I... I hope not.  Sometimes it doesn't happen, for example right now, I
can't reproduce the issue with another, sleeping, Emacs.

I wonder if Emacs, like Firefox, also does not hang indefinitely when it
happens?  I didn't have that impression, but as I said, I can't test
ATM.

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Thierry Volpiatto <thievol <at> posteo.net>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Sat, 06 Mar 2021 03:55:38 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> > IOW the block in subr.el:
> >
> >     (setq while-no-input-ignore-events
> >           '(focus-in focus-out help-echo iconify-frame
> >             make-frame-visible selection-request))
> >
> > is not evaled, it is in emacs-26.3.

After using Emacs now for half a day with this expression added to my
config I can acknowledge that it solves part (2) of this report.  As
said, I don't understand why the expression in subr.el has no effect.

Michael.

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

From: Thierry Volpiatto <thievol <at> posteo.net>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Sat, 06 Mar 2021 07:11:01 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> > IOW the block in subr.el:
>> >
>> >     (setq while-no-input-ignore-events
>> >           '(focus-in focus-out help-echo iconify-frame
>> >             make-frame-visible selection-request))
>> >
>> > is not evaled, it is in emacs-26.3.
>
> After using Emacs now for half a day with this expression added to my
> config I can acknowledge that it solves part (2) of this report.  As
> said, I don't understand why the expression in subr.el has no effect.

See bug#46940, Eli fixed it in emacs-27 branch.

-- 
Thierry

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Sat, 06 Mar 2021 13:33:53 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> I wonder if Emacs, like Firefox, also does not hang indefinitely when it
> happens?  I didn't have that impression, but as I said, I can't test
> ATM.

No, Emacs hangs forever -- that is, until you hit `C-g'.

We could add a timeout for this...  but yanking data can take an
arbitrary amount of time, so I'm not sure we want to go in that
direction, either.  For instance, if the process we're yanking from is
busy doing something else for a couple of seconds, we will get the data
after it stops being busy, and a timeout that's longer than a couple of
seconds isn't very useful anyway.

So I think the current design -- just wait indefinitely, or until the
user says `C-g' -- is probably the correct one.  Any opinions?

In the default Emacs settings, you're only affected when actually trying
to paste something from other programs, but if you have a package/use
settings that make Emacs interact with the clipboard/primary selection
all the time (which it sounds like you have?), then the problem is
exacerbated, of course.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Sun, 07 Mar 2021 01:03:22 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> So I think the current design -- just wait indefinitely, or until the
> user says `C-g' -- is probably the correct one.  Any opinions?

Let me again say that it can be very annoying.  "Some Program is busy
for a long time" can already be fulfilled with "some program is
downloading something from the Internet" which can take...very long, I
live in Germany.

> In the default Emacs settings, you're only affected when actually trying
> to paste something from other programs, but if you have a package/use
> settings that make Emacs interact with the clipboard/primary selection
> all the time (which it sounds like you have?),

All the time?  Not that I knew.  No package.  And only the options that
are provided by vanilla Emacs.  But now I found this option:
`x-selection-timeout'.  Shouldn't that be "our" variable?  Seems I have
set it to 0 (meaning infinity) in my config.  Here on this system the
variable is initialized with 5000 (milliseconds).

But ok, when this behavior is expected when I want Emacs to directly
interact with the clipboard whenever I kill something (maybe that's what
you meant with "all the time"?) and nobody disagrees with that, then I
consider this part of the report as done.

Thanks so far,

Michael.

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Thierry Volpiatto <thievol <at> posteo.net>
Cc: 46935 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Sun, 07 Mar 2021 01:07:19 +0100

Thierry Volpiatto <thievol <at> posteo.net> writes:

> >> >     (setq while-no-input-ignore-events
> >> >           '(focus-in focus-out help-echo iconify-frame
> >> >             make-frame-visible selection-request))
> >> >
> >> > is not evaled, it is in emacs-26.3.
> >
> > After using Emacs now for half a day with this expression added to my
> > config I can acknowledge that it solves part (2) of this report.  As
> > said, I don't understand why the expression in subr.el has no effect.
>
> See bug#46940, Eli fixed it in emacs-27 branch.

Ok, good, thanks.  @Eli: your fix arrive in master automatically sooner
or later, or will it be fixed in some other way - or does it require
manual intervention?


Thanks,

Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: thievol <at> posteo.net, 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Sun, 07 Mar 2021 08:07:46 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: 46935 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Sun, 07 Mar 2021 01:07:19 +0100
> 
> > See bug#46940, Eli fixed it in emacs-27 branch.
> 
> Ok, good, thanks.  @Eli: your fix arrive in master automatically sooner
> or later, or will it be fixed in some other way - or does it require
> manual intervention?

It does require some manual intervention: the merges from emacs-27 to
master aren't completely automatic.  But it will happen pretty soon, I
hope.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Mon, 08 Mar 2021 20:26:54 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> All the time?  Not that I knew.  No package.  And only the options that
> are provided by vanilla Emacs.  But now I found this option:
> `x-selection-timeout'.  Shouldn't that be "our" variable?  Seems I have
> set it to 0 (meaning infinity) in my config.  Here on this system the
> variable is initialized with 5000 (milliseconds).

Ah, I thought Emacs hung forever, but it turns out I was just too
impatient.  Emacs does indeed hang for just five seconds (when testing
with two "emacs -Q"s).

> But ok, when this behavior is expected when I want Emacs to directly
> interact with the clipboard whenever I kill something (maybe that's what
> you meant with "all the time"?) and nobody disagrees with that, then I
> consider this part of the report as done.

Killing text shouldn't hang Emacs, I'd have thought -- but yanking text
will (if you've set up your Emacs to yank from the X
selection/clipboard).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Tue, 09 Mar 2021 04:01:14 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> > `x-selection-timeout'.  Shouldn't that be "our" variable?  Seems I have
> > set it to 0 (meaning infinity) in my config.  Here on this system the
> > variable is initialized with 5000 (milliseconds).
>
> Ah, I thought Emacs hung forever, but it turns out I was just too
> impatient.  Emacs does indeed hang for just five seconds (when testing
> with two "emacs -Q"s).

Would it be appropriate and technically possible to implement a visual
feedback like "waiting up to X seconds for feedback from whatever" or
even a little countdown "waiting for feedback from system clipboard, 3,
2, 1, giving up" or so?


> Killing text shouldn't hang Emacs, I'd have thought [...]

Question is whether that can be avoided.  Does anybody know?


Regards,

Michael.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Tue, 09 Mar 2021 15:11:27 +0100

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> Would it be appropriate and technically possible to implement a visual
> feedback like "waiting up to X seconds for feedback from whatever" or
> even a little countdown "waiting for feedback from system clipboard, 3,
> 2, 1, giving up" or so?

Looking at the code (it's receive_incremental_selection that does this
stuff, I guess?), it seems like it should be possible to implement
something like that in wait_for_property_change.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Wed, 10 Mar 2021 03:10:03 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> > Would it be appropriate and technically possible to implement a visual
> > feedback like "waiting up to X seconds for feedback from whatever" or
> > even a little countdown "waiting for feedback from system clipboard, 3,
> > 2, 1, giving up" or so?

> Looking at the code (it's receive_incremental_selection that does this
> stuff, I guess?), it seems like it should be possible to implement
> something like that in wait_for_property_change.

Ok, so to implement this is my suggestion, and I think the only thing
that developed from this discussion (with other words: this report can
be closed when this has been done or rejected).  I can't implement it
though because I don't speak C.

Michael.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 46935 <at> debbugs.gnu.org, Po Lu <luangruo <at> yahoo.com>
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Mon, 20 Jun 2022 13:53:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

>> All the time?  Not that I knew.  No package.  And only the options that
>> are provided by vanilla Emacs.  But now I found this option:
>> `x-selection-timeout'.  Shouldn't that be "our" variable?  Seems I have
>> set it to 0 (meaning infinity) in my config.  Here on this system the
>> variable is initialized with 5000 (milliseconds).
>
> Ah, I thought Emacs hung forever, but it turns out I was just too
> impatient.  Emacs does indeed hang for just five seconds (when testing
> with two "emacs -Q"s).

The current trunk is back to hanging forever in this scenario.  Test
case:

$ emacs -Q

Then select some text with the mouse and then `C-z' in the shell to stop
the Emacs.

Then start a new "emacs -Q" and use mouse-2 to paste.  Emacs will now
hang forever (until you hit C-g).  So it seems like things have possibly
regressed a bit, since it used to heed x-selection-timeout?

Perhaps Po has some insights here; added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Po Lu <luangruo <at> yahoo.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Mon, 20 Jun 2022 20:59:15 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> The current trunk is back to hanging forever in this scenario.  Test
> case:
>
> $ emacs -Q
>
> Then select some text with the mouse and then `C-z' in the shell to stop
> the Emacs.
>
> Then start a new "emacs -Q" and use mouse-2 to paste.  Emacs will now
> hang forever (until you hit C-g).  So it seems like things have possibly
> regressed a bit, since it used to heed x-selection-timeout?
>
> Perhaps Po has some insights here; added to the CCs.

Thanks, should be fixed now.  The problem was wait_reading_process_input
skipping the call to select upon detect_input_pending even when just
waiting for a cell, without anyone reading keyboard input from the
keyboard buffer.

This bug has existed for a long time.  I wonder why it was only just
reported.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Mon, 20 Jun 2022 17:34:44 +0200

Po Lu <luangruo <at> yahoo.com> writes:

> Thanks, should be fixed now.  The problem was wait_reading_process_input
> skipping the call to select upon detect_input_pending even when just
> waiting for a cell, without anyone reading keyboard input from the
> keyboard buffer.

Thanks; I can confirm that it works fine now.

> This bug has existed for a long time.  I wonder why it was only just
> reported.

Unfortunately, people have a tendency to just live with quirks like this
instead of reporting it...

Anyway, it was suggested to issue a message if the selection takes a
long time, so I've now added this.  I wasn't quite sure on what level,
but `gui-backend-get-selection' seems an OK place.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Po Lu <luangruo <at> yahoo.com>, 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Wed, 22 Jun 2022 14:46:15 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> > This bug has existed for a long time.  I wonder why it was only just
> > reported.
>
> Unfortunately, people have a tendency to just live with quirks like this
> instead of reporting it...

People might also think that it just might be their fault.

> Anyway, it was suggested to issue a message if the selection takes a
> long time, so I've now added this.  I wasn't quite sure on what level,
> but `gui-backend-get-selection' seems an OK place.

Seems to work well for me.  Thanks!

Can we close this one?

Thanks,

Michael.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Po Lu <luangruo <at> yahoo.com>, 46935 <at> debbugs.gnu.org
Subject: Re: bug#46935: 28.0.50; Annoying interactions with X clipboard
Date: Thu, 23 Jun 2022 11:02:20 +0200

Michael Heerdegen <michael_heerdegen <at> web.de> writes:

>> Anyway, it was suggested to issue a message if the selection takes a
>> long time, so I've now added this.  I wasn't quite sure on what level,
>> but `gui-backend-get-selection' seems an OK place.
>
> Seems to work well for me.  Thanks!
>
> Can we close this one?

Yup; now done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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