bug#19945: emacsclient confused by active minibuffer

bug#19945: emacsclient confused by active minibuffer

[Noé Rubinstein]

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

Steps to reproduce:
* In terminal 1: emacs -Q -nw
* M-x server-start RET
* M-x
* In terminal 2: emacsclient -t foo.txt

Expected result:
* terminal 1 displays *scratch*
* terminal 2 displays foo.txt

Actual result:
* Both terminal 1 and terminal 2 display *scratch*
* 5 seconds later, terminal 1 displays foo.txt prepended with "1;2802;0cd";
terminal 2 displays *scratch*
 (this is the opposite of the expected result)

Tested in xterm.

In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2015-01-11 on maritornes, modified by Debian
System Description:     Debian GNU/Linux 7.7 (wheezy)

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/\
share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/\
share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat

 -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-z,relro'

Important settings:
  value of $LANG: fr_FR.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils cc-langs cl-loaddefs cl-lib cc-mode
cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
cc-vars cc-defs server xterm time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer 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 make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

-- 
Noé Rubinstein.

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

bug#19945: emacsclient confused by active minibuffer

[Lars Ingebrigtsen]

Noé Rubinstein <noe.rubinstein@gmail.com> writes:

> Steps to reproduce:
> * In terminal 1: emacs -Q -nw
> * M-x server-start RET
> * M-x
> * In terminal 2: emacsclient -t foo.txt
>
> Expected result:
> * terminal 1 displays *scratch*
> * terminal 2 displays foo.txt
>
> Actual result:
> * Both terminal 1 and terminal 2 display *scratch*

(This bug report unfortunately got no response at the time.)

I can reproduce this behaviour in Emacs 28...

> * 5 seconds later, terminal 1 displays foo.txt prepended with "1;2802;0cd";
> terminal 2 displays *scratch*
>  (this is the opposite of the expected result)

... but not this -- terminal 2 displays foo.txt and terminal 1 displays
*scratch*, so it seems like this bit was fixed, at least.

But the first point still stands -- terminal 2 displays *scratch* first,
and then, one second later, switches to *foo* -- presumably there's
something timing out the `M-x' thing?

Does anybody have any insight into what might be happening here?

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

bug#19945: emacsclient confused by active minibuffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 03 Dec 2020 12:44:08 +0100
> Cc: 19945@debbugs.gnu.org
> 
> But the first point still stands -- terminal 2 displays *scratch* first,
> and then, one second later, switches to *foo* -- presumably there's
> something timing out the `M-x' thing?
> 
> Does anybody have any insight into what might be happening here?

We wait for echo-keystrokes seconds, I presume.

bug#19945: emacsclient confused by active minibuffer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> But the first point still stands -- terminal 2 displays *scratch* first,
>> and then, one second later, switches to *foo* -- presumably there's
>> something timing out the `M-x' thing?
>> 
>> Does anybody have any insight into what might be happening here?
>
> We wait for echo-keystrokes seconds, I presume.

Yes, that seems to be it -- but why is emacsclient doing that instead of
ending the interaction immediately?  Is it doing this on purpose (to
show that we're in the middle of some keyboard action in some other
frame), or is it a bug?

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

bug#19945: emacsclient confused by active minibuffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 19945@debbugs.gnu.org,  noe.rubinstein@gmail.com
> Date: Fri, 04 Dec 2020 10:51:50 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> But the first point still stands -- terminal 2 displays *scratch* first,
> >> and then, one second later, switches to *foo* -- presumably there's
> >> something timing out the `M-x' thing?
> >> 
> >> Does anybody have any insight into what might be happening here?
> >
> > We wait for echo-keystrokes seconds, I presume.
> 
> Yes, that seems to be it -- but why is emacsclient doing that instead of
> ending the interaction immediately?

It isn't emacsclient that's doing this.  Remember: emacsclient just
sends a command to Emacs via a socket; processing of that command and
displaying the results on the frame's display is done by the server,
i.e. by Emacs.

So it's Emacs that's waiting, probably inside sit_for.

bug#19945: emacsclient confused by active minibuffer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> It isn't emacsclient that's doing this.  Remember: emacsclient just
> sends a command to Emacs via a socket; processing of that command and
> displaying the results on the frame's display is done by the server,
> i.e. by Emacs.
>
> So it's Emacs that's waiting, probably inside sit_for.

Well, Emacs is in a recursive minibuffer (since there's an `M-x' in
action), and the server code is ending it when emacsclient talks to it.

But waits a second first.

My question was whether this wait is on purpose (to notify the user that
we're ending the M-x), or whether it's a bug.

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

bug#19945: emacsclient confused by active minibuffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 19945@debbugs.gnu.org,  noe.rubinstein@gmail.com
> Date: Sun, 06 Dec 2020 13:55:48 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It isn't emacsclient that's doing this.  Remember: emacsclient just
> > sends a command to Emacs via a socket; processing of that command and
> > displaying the results on the frame's display is done by the server,
> > i.e. by Emacs.
> >
> > So it's Emacs that's waiting, probably inside sit_for.
> 
> Well, Emacs is in a recursive minibuffer (since there's an `M-x' in
> action), and the server code is ending it when emacsclient talks to it.
> 
> But waits a second first.
> 
> My question was whether this wait is on purpose (to notify the user that
> we're ending the M-x), or whether it's a bug.

It's neither, AFAIU.  It's just that sit_for is not interrupted by the
client attempting to connect (like it would by keyboard input, for
example).  If I'm right, then TRT, IMO, would be to arrange for it to
be interrupted in this case.

(The wait in this case is to provide echo for the key sequence when
the user stops typing for a while, but cease waiting immediately when
new input arrives.)

bug#19945: emacsclient confused by active minibuffer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> My question was whether this wait is on purpose (to notify the user that
>> we're ending the M-x), or whether it's a bug.
>
> It's neither, AFAIU.  It's just that sit_for is not interrupted by the
> client attempting to connect (like it would by keyboard input, for
> example).  If I'm right, then TRT, IMO, would be to arrange for it to
> be interrupted in this case.
>
> (The wait in this case is to provide echo for the key sequence when
> the user stops typing for a while, but cease waiting immediately when
> new input arrives.)

I'm not sure what sit-for you're referring to here.

The user hits

`M-x'

which enters a recursive edit, and the "M-x" is displayed immediately.
Then, sometime much later, the user says "emacsclient -nw".  Then there
is a one-second delay, and then the Emacs server filter executes the
actions the client asked for.

Now, the recursive edit is exited by `server-goto-toplevel', but
instrumenting all of this (i.e., the server filter function) is giving
me inconsistent results -- that is, I can't actually pinpoint where in
the code the wait is happening...  perhaps because some redisplay is
inhibited somewhere?  I'm not sure; it's somewhat frustrating...

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

bug#19945: emacsclient confused by active minibuffer

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 19945@debbugs.gnu.org,  noe.rubinstein@gmail.com
> Date: Mon, 07 Dec 2020 14:17:12 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> My question was whether this wait is on purpose (to notify the user that
> >> we're ending the M-x), or whether it's a bug.
> >
> > It's neither, AFAIU.  It's just that sit_for is not interrupted by the
> > client attempting to connect (like it would by keyboard input, for
> > example).  If I'm right, then TRT, IMO, would be to arrange for it to
> > be interrupted in this case.
> >
> > (The wait in this case is to provide echo for the key sequence when
> > the user stops typing for a while, but cease waiting immediately when
> > new input arrives.)
> 
> I'm not sure what sit-for you're referring to here.

Not sit-for, sit_for.  This one:

	  tem0 = sit_for (Vecho_keystrokes, 1, 1);

You did say we are stuck there for the duration of that 1 sec, didn't
you?  So I'm saying that the problem might be that the connection from
the client doesn't stop sit_for's waiting, and one possible solution
is to arrange it to do so.

Does that make sense?

bug#19945: emacsclient confused by active minibuffer

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm not sure what sit-for you're referring to here.
>
> Not sit-for, sit_for.  This one:
>
> 	  tem0 = sit_for (Vecho_keystrokes, 1, 1);
>
> You did say we are stuck there for the duration of that 1 sec, didn't
> you?  So I'm saying that the problem might be that the connection from
> the client doesn't stop sit_for's waiting, and one possible solution
> is to arrange it to do so.
>
> Does that make sense?

Not immediately.  :-)

I though that that variable was for echoing unfinished (i.e., partial)
keystrokes?   When doing an `M-x', there no timeout for displaying the
`M-x', so it's not clear to me why that should influence anything.

In any case, I thought I could experiment with changing the timeout to
confirm (or not) this hypothesis, but...  I can't reproduce the reported
behaviour any more: "emacsclient -c" now pops up without any delay, even
if the server is in a `M-x'.  :-/

Is anybody else seeing this behaviour with the current trunk?

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