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

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: 46935 <at> debbugs.gnu.org
Subject: bug#46935: 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

Previous Next

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