GNU bug report logs - #35180
[gnome-terminal,tilix,terminator] emacs daemon and "package" often inserts [I when opening file

Previous Next

Package: emacs;

Reported by: Han Boetes <hboetes <at> gmail.com>

Date: Sun, 7 Apr 2019 13:34:02 UTC

Severity: normal

Tags: moreinfo

Found in version 27.0.50

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

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sun, 07 Apr 2019 13:34:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Han Boetes <hboetes <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 07 Apr 2019 13:34:02 GMT) Full text and rfc822 format available.

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

From: Han Boetes <hboetes <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Sun, 7 Apr 2019 15:33:21 +0200
[Message part 1 (text/plain, inline)]
From: Han Boetes <hboetes <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; emacs daemon and “package” often inserts [I when opening
file
--text follows this line--

When using this .emacs/init.el:

(custom-set-variables
 '(package-archives
   '(("gnu" . "https://elpa.gnu.org/packages/")
     ("melpa" . "https://melpa.org/packages/")))
 '(package-selected-packages
   '(pager)))
(require 'package)
(unless package--initialized (package-initialize t))
(unless package-archive-contents
  (package-refresh-contents))
(dolist (package package-selected-packages)
  (unless (package-installed-p package)
    (package-install package)))

And starting emacs like this:
  cd .emacs && pkill emacs && rm -rf elpa auto-save-list && pgrep emacs ||
  /usr/local/bin/emacs --no-site-file --no-splash --daemon

And then opening a file with for example:
  emacsclient -nw -c init.el

At the cursor the string "[I" is inserted.

The pager package I selected for this case is because it was the most
primitive package I could find. Any other package triggered the same
behaviour. As you can see it's not even initialized.


In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
 of 2019-04-05 built on janis
Repository revision: f2d22273599f96a731e23b2f6d7571af8bb7bb3f
Repository branch: master
System Description: Debian GNU/Linux buster/sid

Recent messages:
previous-line: Beginning of buffer [8 times]
next-line: End of buffer [3 times]
Saving file /home/han/.emacs.d/init.el...
Wrote /home/han/.emacs.d/init.el
(No changes need to be saved)
When done with a buffer, type C-x #
Making completion list...
funcall-interactively: End of buffer [5 times]
user-error: End of history; no default available [3 times]
funcall-interactively: End of buffer

Configured using:
 'configure --with-x --with-x-toolkit=gtk 'CFLAGS=-O2 -pipe''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY
LIBSELINUX GNUTLS FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE
XIM THREADS LIBSYSTEMD PDUMPER GMP

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail term/xterm xterm server compile
comint ansi-color ring elec-pair autoload radix-tree lisp-mnt mm-archive
message dired dired-loaddefs format-spec rfc822 mml mml-sec epa derived
gnus-util rmail rmail-loaddefs text-property-search time-date mailabbrev
gmm-utils mailheader mm-decode mm-bodies mm-encode mail-utils gnutls
network-stream url-http mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr url-gw nsm rmc puny url-cache url-auth url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util mailcap epg finder-inf package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 297371 134546)
 (symbols 48 12921 2)
 (strings 32 96918 19735)
 (string-bytes 1 3782341)
 (vectors 16 27205)
 (vector-slots 8 1111668 166944)
 (floats 8 31 428)
 (intervals 56 240 12)
 (buffers 992 18))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 09:27:02 GMT) Full text and rfc822 format available.

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

From: Han Boetes <hboetes <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Sat, 27 Apr 2019 11:26:17 +0200
[Message part 1 (text/plain, inline)]
Digging further and stripping out more unnecessary options that are not
required to reproduce this issue: I got down to this:

cd
mv ~/.emacs.d{,.orig}
mkdir .emacs.d
touch .emacs.d/init.el
xrdb -remove
xrdb -query # Just to prove there are no Xresources active

pkill emacs; sleep 1; /usr/local/bin/emacs –no-init-file –no-site-file
–no-splash –daemon; emacsclient -t .emacs.d/init.el

File Edit Options Buffers Tools Emacs-Lisp Help
[I

This happens about 25% of the time. But if I replace “–no-init-file
–no-site-file –no-splash”
 with “-Q” it no longer happens. It seems there is an undocumented
difference here.

I straced it and this is what I got: Check the write() line, see also the
attachment for the complete strace file.

6288  symlink("han <at> janis.6288:1555184048", "/home/han/.emacs.d/.#init.el")
= 0
6288  rt_sigprocmask(SIG_BLOCK, [INT ALRM], [], 8) = 0
6288  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6288  rt_sigprocmask(SIG_BLOCK, [INT ALRM], [], 8) = 0
6288  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6288  timerfd_settime(3, TFD_TIMER_ABSTIME, {it_interval={tv_sec=0,
tv_nsec=0}, it_value={tv_sec=1556356192, tv_nsec=658825215}}, NULL) = 0
6288  rt_sigprocmask(SIG_BLOCK, [INT ALRM], [], 8) = 0
6288  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6288  rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0
6288  brk(0xcae000)                     = 0xcae000
6288  brk(0xca3000)                     = 0xca3000
6288  write(8, "\33[44d\33[K\33[2d\33[?25l[I\33[43;7H\33[30m"..., 80) = 80
6288  rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0
6288  ioctl(8, FIONREAD, [0])           = 0
6288  rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
6288  rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[Message part 2 (text/html, inline)]
[file (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 09:54:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Han Boetes <hboetes <at> gmail.com>
Cc: 35180 <at> debbugs.gnu.org
Subject: Re: bug#35180: 27.0.50;
 emacs daemon and “package” often inserts
 [I when opening file
Date: Sat, 27 Apr 2019 12:52:47 +0300
> From: Han Boetes <hboetes <at> gmail.com>
> Date: Sat, 27 Apr 2019 11:26:17 +0200
> 
> Digging further and stripping out more unnecessary options that are not required to reproduce this issue: I got
> down to this:
> 
> cd
> mv ~/.emacs.d{,.orig}
> mkdir .emacs.d
> touch .emacs.d/init.el
> xrdb -remove
> xrdb -query # Just to prove there are no Xresources active
> 
> pkill emacs; sleep 1; /usr/local/bin/emacs –no-init-file –no-site-file –no-splash –daemon; emacsclient -t
> .emacs.d/init.el
> 
> File Edit Options Buffers Tools Emacs-Lisp Help
> [I
> 
> This happens about 25% of the time. But if I replace “–no-init-file –no-site-file –no-splash”
>  with “-Q” it no longer happens. It seems there is an undocumented difference here.
> 
> I straced it and this is what I got: Check the write() line, see also the attachment for the complete strace file.

I think this is Emacs probing the terminal capabilities, see
terminal-init-xterm in xterm.el.  Try playing with the value of
xterm-query-timeout.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 10:33:02 GMT) Full text and rfc822 format available.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Han Boetes <hboetes <at> gmail.com>
Cc: 35180 <at> debbugs.gnu.org
Subject: Re: bug#35180: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Sat, 27 Apr 2019 12:32:41 +0200
On Apr 27 2019, Han Boetes <hboetes <at> gmail.com> wrote:

> 6288  write(8, "\33[44d\33[K\33[2d\33[?25l[I\33[43;7H\33[30m"..., 80) = 80

"\e[I" is the xterm focus-in event, so it looks like some race condition.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 12:01:02 GMT) Full text and rfc822 format available.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 35180 <at> debbugs.gnu.org, Han Boetes <hboetes <at> gmail.com>
Subject: Re: bug#35180: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Sat, 27 Apr 2019 13:00:11 +0100
[Message part 1 (text/plain, inline)]
Andreas Schwab <schwab <at> linux-m68k.org> writes:

> On Apr 27 2019, Han Boetes <hboetes <at> gmail.com> wrote:
>
>> 6288  write(8, "\33[44d\33[K\33[2d\33[?25l[I\33[43;7H\33[30m"..., 80) = 80
>
> "\e[I" is the xterm focus-in event, so it looks like some race condition.

Indeed.  This behaviour is present in master, but not emacs-26.  Here's
the simplest repro for me under gnome-terminal on GNU/Linux:

0. emacs -Q --daemon=test
1. emacsclient -t -s test

Some environment variables follow my signature.  Although the above is
not reproducible 100% of the time, the following brings it down to 0% of
the time for me:

0. emacs -Q --daemon=test
1. TERM=xterm-direct emacsclient -t -s test

Another thing that brings the reproducibility down to 0% is the
following:

[faces.diff (text/x-diff, inline)]
diff --git a/lisp/faces.el b/lisp/faces.el
index fa526c3506..195430d980 100644
--- a/lisp/faces.el
+++ b/lisp/faces.el
@@ -2266,6 +2266,7 @@ tty-run-terminal-initialization
 this runs the hook `tty-setup-hook'.
 
 If you set `term-file-prefix' to nil, this function does nothing."
+  (message "")
   (setq type (or type (tty-type frame)))
   (let ((alias (tty-find-type
 		(lambda (typ) (assoc typ term-file-aliases)) type)))
[Message part 3 (text/plain, inline)]
I also tried the following:

[xterm.diff (text/x-diff, inline)]
diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index c4b0a8fb6e..94b5d57a06 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -117,6 +117,7 @@ global-map
 (defun xterm-translate-focus-in (_prompt)
   (setf (terminal-parameter nil 'tty-focus-state) 'focused)
   (funcall after-focus-change-function)
+  (message ">>> focus in")
   [])
 
 (defun xterm-translate-focus-out (_prompt)
[Message part 5 (text/plain, inline)]
On successful startup (where [I is not inserted), I am greeted by the
"focus in" message.

On unsuccessful startup (where [I is inserted), the message never
appears, but term/xterm and xterm are present in features.

Could this race somehow be caused by the pdumper?

Thanks,

-- 
Basil

SHELL=/bin/bash
COLORTERM=truecolor
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
LANGUAGE=en_IE:en
XDG_CONFIG_HOME=/home/blc/.config
DESKTOP_SESSION=lightdm-xsession
XDG_SEAT=seat0
PWD=/home/blc/.local/src/emacs
XDG_SESSION_DESKTOP=lightdm-xsession
LOGNAME=blc
XDG_SESSION_TYPE=x11
XAUTHORITY=/home/blc/.Xauthority
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/blc
HOME=/home/blc
LANG=en_IE.UTF-8
VTE_VERSION=5402
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/a0c755f7_f6cf_4729_b8a6_05f4947bd3eb
XDG_SESSION_CLASS=user
TERM=xterm-256color
USER=blc
GNOME_TERMINAL_SERVICE=:1.66
DISPLAY=:0
SHLVL=1
XDG_VTNR=7
XDG_SESSION_ID=2
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
_=/usr/bin/printenv

In GNU Emacs 27.0.50 (build 6, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2019-04-27 built on thunk
Repository revision: 8dc00b2f1e6523c634df3e24379afbe712a32b27
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12003000
System Description: Debian GNU/Linux buster/sid

Configured using:
 'configure 'CC=ccache gcc' 'CFLAGS=-O2 -march=native' --config-cache
 --prefix=/home/blc/.local --with-mailutils --with-x-toolkit=lucid
 --with-modules --with-file-notification=yes --with-x'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS
GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT
LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS
LIBSYSTEMD JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_IE.UTF-8
  locale-coding-system: utf-8-unix

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 13:52:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: hboetes <at> gmail.com, 35180 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#35180: 27.0.50;
 emacs daemon and “package” often inserts
 [I when opening file
Date: Sat, 27 Apr 2019 16:50:47 +0300
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Date: Sat, 27 Apr 2019 13:00:11 +0100
> Cc: 35180 <at> debbugs.gnu.org, Han Boetes <hboetes <at> gmail.com>
> 
> On successful startup (where [I is not inserted), I am greeted by the
> "focus in" message.
> 
> On unsuccessful startup (where [I is inserted), the message never
> appears, but term/xterm and xterm are present in features.

By "race" do you mean that xterm writes from more than one thread to
the same descriptor, which is used by Emacs as keyboard input, and the
two inputs mix up into one large mess?  If not, who is racing whom
here?

> Could this race somehow be caused by the pdumper?

One way of finding out would be to build Emacs --with-dumping=unexec.
I'd be surprised if it turned out to be pdumper, but who knows?

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 13:55:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: contovob <at> tcd.ie, schwab <at> linux-m68k.org
Cc: 35180 <at> debbugs.gnu.org, hboetes <at> gmail.com
Subject: Re: bug#35180: 27.0.50;
 emacs daemon and “package” often inserts
 [I when opening file
Date: Sat, 27 Apr 2019 16:53:53 +0300
> Date: Sat, 27 Apr 2019 16:50:47 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: schwab <at> linux-m68k.org, 35180 <at> debbugs.gnu.org, hboetes <at> gmail.com
> 
> > Could this race somehow be caused by the pdumper?
> 
> One way of finding out would be to build Emacs --with-dumping=unexec.
> I'd be surprised if it turned out to be pdumper, but who knows?

Actually, since focus-in support on a TTY is new in Emacs 27, I'm
quite sure this has nothing to do with the pdumper.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 14:16:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: hboetes <at> gmail.com, 35180 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#35180: 27.0.50;
 emacs daemon and “package” often inserts
 [I when opening file
Date: Sat, 27 Apr 2019 17:14:38 +0300
> From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
> Date: Sat, 27 Apr 2019 13:00:11 +0100
> Cc: 35180 <at> debbugs.gnu.org, Han Boetes <hboetes <at> gmail.com>
> 
> On successful startup (where [I is not inserted), I am greeted by the
> "focus in" message.
> 
> On unsuccessful startup (where [I is inserted), the message never
> appears, but term/xterm and xterm are present in features.

Is it possible that in the unsuccessful cases we fall back to async
management of xterm--query responses?

Maybe it's another manifestation of bug#34821 (xterm--query calls
discard-input)?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 27 Apr 2019 20:36:02 GMT) Full text and rfc822 format available.

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

From: Han Boetes <hboetes <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 35180 <at> debbugs.gnu.org,
 Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#35180: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Sat, 27 Apr 2019 22:35:39 +0200
[Message part 1 (text/plain, inline)]
I was wondering if this is a bug in emacs, or in gnome-terminal/terminator,
since this doesn’t happen with xterm. And do I think this is a bug in emacs
because while reading the strace output, the write line which causes the
bug:
   “\33[45d\33[K\33[2d\33[?25l[I\33[44;7H\33[30m”
should contain: “\33[I”
where in the output it shows: “[I”
missing the “\33”

Here I grepped for ‘write(8,’ in the strace output. What I did was:
  rm file2 ; pkill emacs ; strace -f -o file2 /usr/local/bin/emacs -Q
–daemon
And then from another terminal:
  emacsclient -t ‘.emacs/init.el’
Then: x-c x-k
And after that run
  emacsclient -t ‘.emacs/init.el’ again, knowing this time the buffer would
have focus and won’t get the ‘[I’ inserted. I’ve indented the 2 most
important lines.

han <at> janis ~ % grep 'write\(8,' file2
16051 write(8, "\33[?1049h\33[22;0;0t\33[?12;25h\33[?1h\33"..., 33) = 33
16051 write(8, "\33[>0c", 5)            = 5
16051 write(8, "\33[?2004h", 8)         = 8
16051 write(8, "\33[?1004h", 8)         = 8
16051 write(8, "\33[H\33[2J", 7)        = 7
16051 write(8, "\33[44d\33[?25l\33[30m\33[48;5;250m-UU-:"..., 207) = 207
16051 write(8, "\33[45d\33[?25lWhen done with a buff"..., 164) = 164
16051 write(8,
"\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
16051 write(8,
"\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
16051 write(8,
"\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 229) = 229
  16051 write(8, “\33[45d\33[K\33[2d\33[?25l[I\33[44;7H\33[30m”…, 80) = 80
16051 write(8, "\33[45;1H\33[?25l\33[38;5;20mKill buff"..., 105) = 105
16051 write(8, "\33[45;32H\33[?12l\33[?25h\33[?12;25h", 29) = 29
16051 write(8, "\r", 1)                 = 1
16051 write(8, "\33[?25l\33[38;5;20mBuffer init.el m"..., 74) = 74
16051 write(8, "\33[?12l\33[?25h\33[?12;25h", 21) = 21
16051 write(8, "\33[?25ly\33[?12l\33[?25h\33[?12;25h", 28) = 28
16051 write(8, "\r", 1)                 = 1
16051 write(8, "\7", 1)                 = 1
16051 write(8, "\33[?25lPlease answer yes or no.\33["..., 60) = 60
16051 write(8, "\33[45;1H\33[?25l\33[38;5;20mBuffer in"..., 81) = 81
16051 write(8, "\33[?12l\33[?25h\33[?12;25h", 21) = 21
16051 write(8, "\33[?25ly\33[?12l\33[?25h\33[?12;25h", 28) = 28
16051 write(8, "\33[?25le\33[?12l\33[?25h\33[?12;25h", 28) = 28
16051 write(8, "\33[?25ls\33[?12l\33[?25h\33[?12;25h", 28) = 28
16051 write(8, "\r", 1)                 = 1
16051 write(8, "\33[K", 3)              = 3
16051 write(8, "\33[?1004l\33[?2004l\33[?1l\33>\33[?12l\33[?"..., 61) = 61
16051 write(8, "\33[?1049h\33[22;0;0t\33[?12;25h\33[?1h\33"..., 33) = 33
16051 write(8, "\33[>0c", 5)            = 5
16051 write(8, "\33[?2004h", 8)         = 8
16051 write(8, "\33[?1004h", 8)         = 8
16051 write(8, "\33[H\33[2J", 7)        = 7
16051 write(8, "\33[45d\33[?25lWhen done with a buff"..., 74) = 74
16051 write(8, "\33[45d\33[?25lWhen done with a buff"..., 164) = 164
16051 write(8,
"\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
16051 write(8,
"\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
16051 write(8,
"\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 229) = 229
  16051 write(8, “\33[45d\33[K\33[2d”, 12) = 12
16051 write(8, "\33[45d\33[?25l\33[38;5;20mKill buffer"..., 103) = 103
16051 write(8, "\33[45;32H\33[?12l\33[?25h\33[?12;25h", 29) = 29
16051 write(8, "\r", 1)                 = 1
16051 write(8, "\33[K", 3)              = 3
16051 write(8, “\33[?1004l\33[?2004l\33[?1l\33>\33[?12l\33[?”…, 61) = 61
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sat, 04 May 2019 23:08:01 GMT) Full text and rfc822 format available.

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

From: Han Boetes <hboetes <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "Basil L. Contovounesios" <contovob <at> tcd.ie>, 35180 <at> debbugs.gnu.org,
 Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#35180: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Sun, 5 May 2019 01:07:29 +0200
To summarize my latest finds:
  This problem occurs only with terminator, tilix and gnome-terminal,
not with xterm and rxvt
  This problem does not occur when using tmux in terminator
So it looks like the use of TERM=xterm* in gnome-terminal triggers the
problem. Both tilix and terminator use gnome-terminal as backends IIRC

On Sat, Apr 27, 2019 at 10:35 PM Han Boetes <hboetes <at> gmail.com> wrote:
>
> I was wondering if this is a bug in emacs, or in gnome-terminal/terminator, since this doesn’t happen with xterm. And do I think this is a bug in emacs because while reading the strace output, the write line which causes the bug:
>    “\33[45d\33[K\33[2d\33[?25l[I\33[44;7H\33[30m”
> should contain: “\33[I”
> where in the output it shows: “[I”
> missing the “\33”
>
> Here I grepped for ‘write(8,’ in the strace output. What I did was:
>   rm file2 ; pkill emacs ; strace -f -o file2 /usr/local/bin/emacs -Q –daemon
> And then from another terminal:
>   emacsclient -t ‘.emacs/init.el’
> Then: x-c x-k
> And after that run
>   emacsclient -t ‘.emacs/init.el’ again, knowing this time the buffer would have focus and won’t get the ‘[I’ inserted. I’ve indented the 2 most important lines.
>
> han <at> janis ~ % grep 'write\(8,' file2
> 16051 write(8, "\33[?1049h\33[22;0;0t\33[?12;25h\33[?1h\33"..., 33) = 33
> 16051 write(8, "\33[>0c", 5)            = 5
> 16051 write(8, "\33[?2004h", 8)         = 8
> 16051 write(8, "\33[?1004h", 8)         = 8
> 16051 write(8, "\33[H\33[2J", 7)        = 7
> 16051 write(8, "\33[44d\33[?25l\33[30m\33[48;5;250m-UU-:"..., 207) = 207
> 16051 write(8, "\33[45d\33[?25lWhen done with a buff"..., 164) = 164
> 16051 write(8, "\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
> 16051 write(8, "\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
> 16051 write(8, "\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 229) = 229
>   16051 write(8, “\33[45d\33[K\33[2d\33[?25l[I\33[44;7H\33[30m”…, 80) = 80
> 16051 write(8, "\33[45;1H\33[?25l\33[38;5;20mKill buff"..., 105) = 105
> 16051 write(8, "\33[45;32H\33[?12l\33[?25h\33[?12;25h", 29) = 29
> 16051 write(8, "\r", 1)                 = 1
> 16051 write(8, "\33[?25l\33[38;5;20mBuffer init.el m"..., 74) = 74
> 16051 write(8, "\33[?12l\33[?25h\33[?12;25h", 21) = 21
> 16051 write(8, "\33[?25ly\33[?12l\33[?25h\33[?12;25h", 28) = 28
> 16051 write(8, "\r", 1)                 = 1
> 16051 write(8, "\7", 1)                 = 1
> 16051 write(8, "\33[?25lPlease answer yes or no.\33["..., 60) = 60
> 16051 write(8, "\33[45;1H\33[?25l\33[38;5;20mBuffer in"..., 81) = 81
> 16051 write(8, "\33[?12l\33[?25h\33[?12;25h", 21) = 21
> 16051 write(8, "\33[?25ly\33[?12l\33[?25h\33[?12;25h", 28) = 28
> 16051 write(8, "\33[?25le\33[?12l\33[?25h\33[?12;25h", 28) = 28
> 16051 write(8, "\33[?25ls\33[?12l\33[?25h\33[?12;25h", 28) = 28
> 16051 write(8, "\r", 1)                 = 1
> 16051 write(8, "\33[K", 3)              = 3
> 16051 write(8, "\33[?1004l\33[?2004l\33[?1l\33>\33[?12l\33[?"..., 61) = 61
> 16051 write(8, "\33[?1049h\33[22;0;0t\33[?12;25h\33[?1h\33"..., 33) = 33
> 16051 write(8, "\33[>0c", 5)            = 5
> 16051 write(8, "\33[?2004h", 8)         = 8
> 16051 write(8, "\33[?1004h", 8)         = 8
> 16051 write(8, "\33[H\33[2J", 7)        = 7
> 16051 write(8, "\33[45d\33[?25lWhen done with a buff"..., 74) = 74
> 16051 write(8, "\33[45d\33[?25lWhen done with a buff"..., 164) = 164
> 16051 write(8, "\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
> 16051 write(8, "\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 68) = 68
> 16051 write(8, "\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K\n\33[K"..., 229) = 229
>   16051 write(8, “\33[45d\33[K\33[2d”, 12) = 12
> 16051 write(8, "\33[45d\33[?25l\33[38;5;20mKill buffer"..., 103) = 103
> 16051 write(8, "\33[45;32H\33[?12l\33[?25h\33[?12;25h", 29) = 29
> 16051 write(8, "\r", 1)                 = 1
> 16051 write(8, "\33[K", 3)              = 3
> 16051 write(8, “\33[?1004l\33[?2004l\33[?1l\33>\33[?12l\33[?”…, 61) = 61
>




Changed bug title to '[gnome-terminal,tilix,terminator] emacs daemon and "package" often inserts [I when opening file' from '27.0.50; emacs daemon and “package” often inserts [I when opening file' Request was from npostavs <at> gmail.com to control <at> debbugs.gnu.org. (Thu, 09 May 2019 17:55:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Fri, 04 Oct 2019 20:00:03 GMT) Full text and rfc822 format available.

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

From: Han Boetes <hboetes <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Fri, 4 Oct 2019 21:59:30 +0200
[Message part 1 (text/plain, inline)]
In my continuing search for this problem I installed alacritty, which also
shows a weird fenomena related to this issue:

% echo $TERM
xterm-256color

After restarting the emacs server and opening a file with emacsclient -nw I
have to wait for 2 seconds for emacs to 'focus' after whic h the bar at the
bottom changes to focussed and I can begin typing. If I type for example
the downkey I get OB added at the cursor.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Wed, 18 Dec 2019 19:33:01 GMT) Full text and rfc822 format available.

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

From: Han Boetes <hboetes <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Wed, 18 Dec 2019 20:31:47 +0100
[Message part 1 (text/plain, inline)]
I can't reproduce this bug any more. I tried with alacritty and terminator
and it looks like it's gone.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Sun, 20 Sep 2020 18:08:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: Han Boetes <hboetes <at> gmail.com>, 35180 <at> debbugs.gnu.org,
 Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#35180: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Sun, 20 Sep 2020 20:07:10 +0200
"Basil L. Contovounesios" <contovob <at> tcd.ie> writes:

> Indeed.  This behaviour is present in master, but not emacs-26.  Here's
> the simplest repro for me under gnome-terminal on GNU/Linux:
>
> 0. emacs -Q --daemon=test
> 1. emacsclient -t -s test

I tried reproducing this with Emacs 28 on Debian bullseye a bunch of
times, and I'm unable to.

The original bug reporter was also unable to reproduce the problem any
more -- is anybody still seeing this problem?

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




Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 20 Sep 2020 18:08:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35180; Package emacs. (Tue, 22 Sep 2020 14:09:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Han Boetes <hboetes <at> gmail.com>
Cc: 35180 <at> debbugs.gnu.org
Subject: Re: bug#35180: 27.0.50; emacs daemon and “package” often inserts [I when opening file
Date: Tue, 22 Sep 2020 16:07:54 +0200
Han Boetes <hboetes <at> gmail.com> writes:

> The problem as originally described is gone. The only thing I still noticed, after a
> fresh new start of the emacs daemon, the first time I open any file with
> emacsclient the initial window wasn't focused. The bottom-bar was dark instead of
> using the proper colour. But haven't seen that problem any more either.
>
> I think you can close this problem. Thanks for all the hard work of everyone
> involved.

It sounded like some people were seeing similar things, but that those
were difficult to reproduce, too.

So I'm closing this bug report in the hope that the bug really has gone
away, but if somebody experiences this problem again, perhaps opening a
new bug report would be a good idea.





bug closed, send any further explanations to 35180 <at> debbugs.gnu.org and Han Boetes <hboetes <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 22 Sep 2020 14:09:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 21 Oct 2020 11:24:09 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 158 days ago.

Previous Next


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