GNU bug report logs -
#25097
25.1; Scratch buffer flashes with emacsclient and xterm
Previous Next
Reported by: Jake <jake.waksbaum <at> gmail.com>
Date: Fri, 2 Dec 2016 22:24:01 UTC
Severity: normal
Tags: moreinfo
Found in version 25.1
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 25097 in the body.
You can then email your comments to 25097 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Fri, 02 Dec 2016 22:24:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Jake <jake.waksbaum <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 02 Dec 2016 22:24:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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))
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Thu, 10 May 2018 00:45:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 25097 <at> debbugs.gnu.org (full text, mbox):
Jake <jake.waksbaum <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Wed, 12 Aug 2020 00:36:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 25097 <at> debbugs.gnu.org (full text, mbox):
Noam Postavsky <npostavs <at> gmail.com> writes:
> Jake <jake.waksbaum <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Wed, 12 Aug 2020 14:12:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 25097 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Tue, 11 Aug 2020 17:35:27 -0700
> Cc: Jake <jake.waksbaum <at> gmail.com>, 25097 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Wed, 12 Aug 2020 14:19:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 25097 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Wed, 12 Aug 2020 14:48:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 25097 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 12 Aug 2020 07:18:22 -0700
> Cc: npostavs <at> gmail.com, jake.waksbaum <at> gmail.com, 25097 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Wed, 01 Dec 2021 19:38:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 25097 <at> debbugs.gnu.org (full text, mbox):
Jake <jake.waksbaum <at> 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
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 01 Dec 2021 19:38:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#25097
; Package
emacs
.
(Wed, 01 Dec 2021 22:31:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 25097 <at> debbugs.gnu.org (full text, mbox):
"Jake Waksbaum" <jake.waksbaum <at> 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.
bug closed, send any further explanations to
25097 <at> debbugs.gnu.org and Jake <jake.waksbaum <at> gmail.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Wed, 01 Dec 2021 22:31:03 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
.
(Thu, 30 Dec 2021 12:24:15 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 80 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.