unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#46935: 28.0.50; Annoying interactions with X clipboard
@ 2021-03-04 23:28 Michael Heerdegen
  2021-03-05 13:46 ` Lars Ingebrigtsen
       [not found] ` <87y2f2m551.fsf@posteo.net>
  0 siblings, 2 replies; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-04 23:28 UTC (permalink / raw)
  To: 46935


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






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-04 23:28 bug#46935: 28.0.50; Annoying interactions with X clipboard Michael Heerdegen
@ 2021-03-05 13:46 ` Lars Ingebrigtsen
  2021-03-05 22:48   ` Michael Heerdegen
       [not found] ` <87y2f2m551.fsf@posteo.net>
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-05 13:46 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 46935

Michael Heerdegen <michael_heerdegen@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
       [not found] ` <87y2f2m551.fsf@posteo.net>
@ 2021-03-05 22:43   ` Michael Heerdegen
  2021-03-06  2:55     ` Michael Heerdegen
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-05 22:43 UTC (permalink / raw)
  To: Thierry Volpiatto; +Cc: 46935

Thierry Volpiatto <thievol@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-05 13:46 ` Lars Ingebrigtsen
@ 2021-03-05 22:48   ` Michael Heerdegen
  2021-03-06 12:33     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-05 22:48 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 46935

Lars Ingebrigtsen <larsi@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-05 22:43   ` Michael Heerdegen
@ 2021-03-06  2:55     ` Michael Heerdegen
  2021-03-06  6:11       ` Thierry Volpiatto
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-06  2:55 UTC (permalink / raw)
  To: Thierry Volpiatto; +Cc: 46935

Michael Heerdegen <michael_heerdegen@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-06  2:55     ` Michael Heerdegen
@ 2021-03-06  6:11       ` Thierry Volpiatto
  2021-03-07  0:07         ` Michael Heerdegen
  0 siblings, 1 reply; 19+ messages in thread
From: Thierry Volpiatto @ 2021-03-06  6:11 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 46935


Michael Heerdegen <michael_heerdegen@web.de> writes:

> Michael Heerdegen <michael_heerdegen@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-05 22:48   ` Michael Heerdegen
@ 2021-03-06 12:33     ` Lars Ingebrigtsen
  2021-03-07  0:03       ` Michael Heerdegen
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-06 12:33 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 46935

Michael Heerdegen <michael_heerdegen@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-06 12:33     ` Lars Ingebrigtsen
@ 2021-03-07  0:03       ` Michael Heerdegen
  2021-03-08 19:26         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-07  0:03 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 46935

Lars Ingebrigtsen <larsi@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-06  6:11       ` Thierry Volpiatto
@ 2021-03-07  0:07         ` Michael Heerdegen
  2021-03-07  6:07           ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-07  0:07 UTC (permalink / raw)
  To: Thierry Volpiatto; +Cc: 46935

Thierry Volpiatto <thievol@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-07  0:07         ` Michael Heerdegen
@ 2021-03-07  6:07           ` Eli Zaretskii
  0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2021-03-07  6:07 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: thievol, 46935

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: 46935@debbugs.gnu.org, Eli Zaretskii <eliz@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-07  0:03       ` Michael Heerdegen
@ 2021-03-08 19:26         ` Lars Ingebrigtsen
  2021-03-09  3:01           ` Michael Heerdegen
  2022-06-20 11:53           ` Lars Ingebrigtsen
  0 siblings, 2 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-08 19:26 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 46935

Michael Heerdegen <michael_heerdegen@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-08 19:26         ` Lars Ingebrigtsen
@ 2021-03-09  3:01           ` Michael Heerdegen
  2021-03-09 14:11             ` Lars Ingebrigtsen
  2022-06-20 11:53           ` Lars Ingebrigtsen
  1 sibling, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-09  3:01 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 46935

Lars Ingebrigtsen <larsi@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-09  3:01           ` Michael Heerdegen
@ 2021-03-09 14:11             ` Lars Ingebrigtsen
  2021-03-10  2:10               ` Michael Heerdegen
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2021-03-09 14:11 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 46935

Michael Heerdegen <michael_heerdegen@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-09 14:11             ` Lars Ingebrigtsen
@ 2021-03-10  2:10               ` Michael Heerdegen
  0 siblings, 0 replies; 19+ messages in thread
From: Michael Heerdegen @ 2021-03-10  2:10 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 46935

Lars Ingebrigtsen <larsi@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2021-03-08 19:26         ` Lars Ingebrigtsen
  2021-03-09  3:01           ` Michael Heerdegen
@ 2022-06-20 11:53           ` Lars Ingebrigtsen
  2022-06-20 12:59             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-20 11:53 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: 46935, Po Lu

Lars Ingebrigtsen <larsi@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2022-06-20 11:53           ` Lars Ingebrigtsen
@ 2022-06-20 12:59             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-06-20 15:34               ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-06-20 12:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Michael Heerdegen, 46935

Lars Ingebrigtsen <larsi@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2022-06-20 12:59             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-06-20 15:34               ` Lars Ingebrigtsen
  2022-06-22 12:46                 ` Michael Heerdegen
  0 siblings, 1 reply; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-20 15:34 UTC (permalink / raw)
  To: Po Lu; +Cc: Michael Heerdegen, 46935

Po Lu <luangruo@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2022-06-20 15:34               ` Lars Ingebrigtsen
@ 2022-06-22 12:46                 ` Michael Heerdegen
  2022-06-23  9:02                   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 19+ messages in thread
From: Michael Heerdegen @ 2022-06-22 12:46 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Po Lu, 46935

Lars Ingebrigtsen <larsi@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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#46935: 28.0.50; Annoying interactions with X clipboard
  2022-06-22 12:46                 ` Michael Heerdegen
@ 2022-06-23  9:02                   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 19+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-23  9:02 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Po Lu, 46935

Michael Heerdegen <michael_heerdegen@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





^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-06-23  9:02 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-04 23:28 bug#46935: 28.0.50; Annoying interactions with X clipboard Michael Heerdegen
2021-03-05 13:46 ` Lars Ingebrigtsen
2021-03-05 22:48   ` Michael Heerdegen
2021-03-06 12:33     ` Lars Ingebrigtsen
2021-03-07  0:03       ` Michael Heerdegen
2021-03-08 19:26         ` Lars Ingebrigtsen
2021-03-09  3:01           ` Michael Heerdegen
2021-03-09 14:11             ` Lars Ingebrigtsen
2021-03-10  2:10               ` Michael Heerdegen
2022-06-20 11:53           ` Lars Ingebrigtsen
2022-06-20 12:59             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-06-20 15:34               ` Lars Ingebrigtsen
2022-06-22 12:46                 ` Michael Heerdegen
2022-06-23  9:02                   ` Lars Ingebrigtsen
     [not found] ` <87y2f2m551.fsf@posteo.net>
2021-03-05 22:43   ` Michael Heerdegen
2021-03-06  2:55     ` Michael Heerdegen
2021-03-06  6:11       ` Thierry Volpiatto
2021-03-07  0:07         ` Michael Heerdegen
2021-03-07  6:07           ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).