bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Jake]

[-- Attachment #1: Type: text/plain, Size: 3359 bytes --]

When I run

     emacs -Q --daemon
     emacsclient -t foo.txt

to open some file foo.txt, the scratch buffer displays for 2-3 seconds
before the buffer for the file actually opens. My TERM environment
variable is set to "xterm-256color", and if I change it to
"screen-256color" this problem goes away. Also if I create a file
containing only "(setq-default xterm-query-timeout nil)" and load that
with the -l flag, the problem goes away. Presumably there is a purpose
to this timeout, so just doing this is probably not ideal. It was
added in commit cc8f96e in response to bug#12345.


In GNU Emacs 25.1.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2016-12-02 built on localhost
Repository revision: f0eb70d8935be90f7c03e187c12d9b60e7214cc6
System Description: Ubuntu 14.04.5 LTS

Configured using:
 'configure --with-x-toolkit=lucid'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF
GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT
ZLIB TOOLKIT_SCROLL_BARS LUCID X11

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

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-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

Recent messages:
Starting Emacs daemon.
When done with this frame, type C-x 5 0
C-c C-x C-c is undefined
When done with a buffer, type C-x #
user-error: Beginning of history; no preceding item
user-error: End of history; no default available

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils term/xterm xterm server
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core 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 charscript case-table epa-hook
jka-cmpr-hook help simple abbrev 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 dbusbind inotify dynamic-setting
system-font-setting font-render-setting x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 91582 7267)
 (symbols 48 19907 0)
 (miscs 40 53 171)
 (strings 32 14939 4622)
 (string-bytes 1 424663)
 (vectors 16 10034)
 (vector-slots 8 390451 13298)
 (floats 8 171 483)
 (intervals 56 193 0)
 (buffers 976 21)
 (heap 1024 29106 799))

[-- Attachment #2: Type: text/html, Size: 4517 bytes --]

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Noam Postavsky]

Jake <jake.waksbaum@gmail.com> writes:

> When I run
>
>      emacs -Q --daemon
>      emacsclient -t foo.txt
>
> to open some file foo.txt, the scratch buffer displays for 2-3 seconds
> before the buffer for the file actually opens. My TERM environment
> variable is set to "xterm-256color", and if I change it to
> "screen-256color" this problem goes away. Also if I create a file
> containing only "(setq-default xterm-query-timeout nil)" and load that
> with the -l flag, the problem goes away. Presumably there is a purpose
> to this timeout, so just doing this is probably not ideal. It was
> added in commit cc8f96e in response to bug#12345.

That commit actually changed the timeout from a hardcoded 2, and makes
the timeout configurable.  So I think setting xterm-query-timeout to nil
is the right thing here.  Perhaps even a nil xterm-query-timeout should
be the default?

Here's another case where that seems to help:

https://emacs.stackexchange.com/questions/16878/0950c-escape-code-is-inserted-with-typeahead-in-terminal-emacs

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Stefan Kangas]

Noam Postavsky <npostavs@gmail.com> writes:

> Jake <jake.waksbaum@gmail.com> writes:
>
>> When I run
>>
>>      emacs -Q --daemon
>>      emacsclient -t foo.txt
>>
>> to open some file foo.txt, the scratch buffer displays for 2-3 seconds
>> before the buffer for the file actually opens. My TERM environment
>> variable is set to "xterm-256color", and if I change it to
>> "screen-256color" this problem goes away. Also if I create a file
>> containing only "(setq-default xterm-query-timeout nil)" and load that
>> with the -l flag, the problem goes away. Presumably there is a purpose
>> to this timeout, so just doing this is probably not ideal. It was
>> added in commit cc8f96e in response to bug#12345.
>
> That commit actually changed the timeout from a hardcoded 2, and makes
> the timeout configurable.  So I think setting xterm-query-timeout to nil
> is the right thing here.  Perhaps even a nil xterm-query-timeout should
> be the default?
>
> Here's another case where that seems to help:
>
> https://emacs.stackexchange.com/questions/16878/0950c-escape-code-is-inserted-with-typeahead-in-terminal-emacs

Should we just go ahead and change it, then?  From reading the SE
comment, there seems to be no concrete reason to not set it to nil by
default.

Best regards,
Stefan Kangas

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 11 Aug 2020 17:35:27 -0700
> Cc: Jake <jake.waksbaum@gmail.com>, 25097@debbugs.gnu.org
> 
> > That commit actually changed the timeout from a hardcoded 2, and makes
> > the timeout configurable.  So I think setting xterm-query-timeout to nil
> > is the right thing here.  Perhaps even a nil xterm-query-timeout should
> > be the default?
> >
> > Here's another case where that seems to help:
> >
> > https://emacs.stackexchange.com/questions/16878/0950c-escape-code-is-inserted-with-typeahead-in-terminal-emacs
> 
> Should we just go ahead and change it, then?  From reading the SE
> comment, there seems to be no concrete reason to not set it to nil by
> default.

I don't see how such a conclusion follows from that discussion; what
did I miss?

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Should we just go ahead and change it, then?  From reading the SE
>> comment, there seems to be no concrete reason to not set it to nil by
>> default.
>
> I don't see how such a conclusion follows from that discussion; what
> did I miss?

That's mainly in reference to this comment:

    There is a comment in xterm--query saying "Maybe we could always use
    the asynchronous approach, but it's less tested." In other words,
    the timeout was left in because of worries about adverse side
    effects. But there aren't any known problems for the asynch method
    (as far as I can see). – npostavs May 9 '18 at 16:00

Best regards,
Stefan Kangas

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 12 Aug 2020 07:18:22 -0700
> Cc: npostavs@gmail.com, jake.waksbaum@gmail.com, 25097@debbugs.gnu.org
> 
> > I don't see how such a conclusion follows from that discussion; what
> > did I miss?
> 
> That's mainly in reference to this comment:
> 
>     There is a comment in xterm--query saying "Maybe we could always use
>     the asynchronous approach, but it's less tested." In other words,
>     the timeout was left in because of worries about adverse side
>     effects. But there aren't any known problems for the asynch method
>     (as far as I can see). – npostavs May 9 '18 at 16:00

OTOH, the problem being discussed is also very rare, so I'm not sure
we should make radical decisions based on that.

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Lars Ingebrigtsen]

Jake <jake.waksbaum@gmail.com> writes:

> When I run
>
>      emacs -Q --daemon
>      emacsclient -t foo.txt
>
> to open some file foo.txt, the scratch buffer displays for 2-3 seconds
> before the buffer for the file actually opens. My TERM environment
> variable is set to "xterm-256color", and if I change it to
> "screen-256color" this problem goes away.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I'm not able to reproduce this.  Are you still seeing this issue in more
recent versions of Emacs (and/or the OS)?

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

bug#25097: 25.1; Scratch buffer flashes with emacsclient and xterm

[Lars Ingebrigtsen]

"Jake Waksbaum" <jake.waksbaum@gmail.com> writes:

>> I'm not able to reproduce this. Are you still seeing this issue in more
>> recent versions of Emacs (and/or the OS)?
>
> At this point, I'm on a totally different setup probably, and I don't
> have this problem anymore, so I'm good with this issue being resolved.

OK; closing this bug report, then.