bug#43645: 26.3; emacsclient -c does not open to correct window

bug#43645: 26.3; emacsclient -c does not open to correct window

[Blue track]

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

When opening an emacsclient instance to a new intance of a buffer which
is already open, under some conditions it does not open to the correct
buffer.

To reproduce:
```
emacs -Q --daemon

echo "Test" > test.txt
emacsclient -c test.txt
C-x 3
C-x b *scratch*

# In new terminal
emacsclient -c test.txt

# I get a new window with the *scratch* buffer, but under Ubuntu 20.04 the
first emacsclient intance is on top also
```


In GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.14)
 of 2020-03-26, modified by Debian built on lcy01-amd64-020
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Ubuntu 20.04.1 LTS

Recent messages:
Quit
Undo!
Mark set [2 times]
Quit [4 times]
C-h C-g is undefined
When done with this frame, type C-x 5 0
Quit [2 times]
Mark activated
Mark set
Quit [2 times]
next-line: End of buffer
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 --enable-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/26.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/26.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-mEZBk7/emacs-26.3+1=.
-fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

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

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

Major mode: Fundamental

Minor modes in effect:
  recentf-mode: t
  diff-auto-refine-mode: t
  global-so-long-mode: t
  shell-dirtrack-mode: t
  global-undo-tree-mode: t
  ivy-mode: t
  global-hl-line-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-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 emacsbug sendmail conf-mode dabbrev novice org-table
css-mode misearch multi-isearch org-indent org-rmail org-mhe org-irc
org-info org-gnus nnir gnus-sum gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source tls gnutls utf7 netrc nnoo
gnus-spec gnus-int gnus-range message rmc puny rfc822 mml mml-sec epa
epg epg-config mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums mail-utils mm-util mail-prsvr
org-docview doc-view image-mode org-bibtex bibtex org-bbdb org-w3m
goto-addr view python tramp-sh mail-extr recentf tree-widget wid-edit
bookmark pp autorevert filenotify ffap tramp tramp-compat tramp-loaddefs
trampver ucs-normalize parse-time windmove face-remap flyspell ispell
vc-git diff-mode server elec-pair git-gutter dockerfile-mode sh-script
smie executable s so-long js2-mode etags js sgml-mode dom flycheck json
map subr-x seq jka-compr let-alist dash web-mode disp-table powershell
shell csharp-mode imenu cc-langs cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs markdown-mode rx
url-parse auth-source password-cache url-vars thingatpt undo-tree diff
counsel xdg xref project eieio byte-opt bytecomp byte-compile cconv
eieio-core eieio-loaddefs dired dired-loaddefs compile swiper cl-extra
help-mode ivy derived delsel ivy-overlay colir org-bullets edmacro
kmacro fill-column-indicator rainbow-delimiters rainbow-mode cl-macs
color cl gv hl-line base16-custom-theme base16-theme pcase org-element
cl-seq avl-tree generator org advice org-macro org-footnote
org-pcomplete pcomplete org-list org-faces org-entities time-date
noutline outline easy-mmode org-version ob-emacs-lisp ob ob-tangle
org-src ob-ref ob-lob ob-table ob-keys ob-exp ob-comint comint
ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs
format-spec find-func cal-menu easymenu calendar cal-loaddefs
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 lcms2 dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 1316058 202171)
 (symbols 48 62374 1)
 (miscs 40 26716 8353)
 (strings 32 155100 14439)
 (string-bytes 1 4894801)
 (vectors 16 97667)
 (vector-slots 8 2404231 18878)
 (floats 8 709 903)
 (intervals 56 51863 1166)
 (buffers 992 115))

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

bug#43645: 26.3; emacsclient -c does not open to correct window

[Eli Zaretskii]

> From: Blue track <bluetrack121@gmail.com>
> Date: Sun, 27 Sep 2020 16:41:31 +1000
> 
> When opening an emacsclient instance to a new intance of a buffer which
> is already open, under some conditions it does not open to the correct
> buffer.

I think this problem was fixed in Emacs 27.1, so please upgrade and
try again.  If the problem persists, please tell the details.

(I couldn't reproduce this in Emacs 27, FTR.)

Thanks.

bug#43645: 26.3; emacsclient -c does not open to correct window

[Blue track]

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

Thanks for the response, it did not fix the issue. I hope this doesn't
sound condescending but did you follow the steps to reproduce? It's a weird
behaviour which I think is related to window splits:

```
emacs -Q --daemon

echo "Test" > test.txt
emacsclient -c test.txt
C-x 3
C-x b *scratch*

# In new terminal
emacsclient -c test.txt

# I get a new window with the *scratch* buffer, but under Ubuntu 20.04 the
first emacsclient instance is on top also
```




On Sun, 27 Sep 2020 at 19:58, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Blue track <bluetrack121@gmail.com>
> > Date: Sun, 27 Sep 2020 16:41:31 +1000
> >
> > When opening an emacsclient instance to a new intance of a buffer which
> > is already open, under some conditions it does not open to the correct
> > buffer.
>
> I think this problem was fixed in Emacs 27.1, so please upgrade and
> try again.  If the problem persists, please tell the details.
>
> (I couldn't reproduce this in Emacs 27, FTR.)
>
> Thanks.
>

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

bug#43645: 26.3; emacsclient -c does not open to correct window

[Eli Zaretskii]

> From: Blue track <bluetrack121@gmail.com>
> Date: Sun, 27 Sep 2020 20:36:05 +1000
> Cc: 43645@debbugs.gnu.org
> 
> Thanks for the response, it did not fix the issue. I hope this doesn't sound condescending but did you follow
> the steps to reproduce?

Yes, I did.  Of course.  Except that I used -t instead of -c (because
my session wasn't a GUI one).  Maybe that's the difference?

I guess someone else will have to reproduce this and debug.

bug#43645: 26.3; emacsclient -c does not open to correct window

[Lars Ingebrigtsen]

Blue track <bluetrack121@gmail.com> writes:

> emacs -Q --daemon
>
> echo "Test" > test.txt
> emacsclient -c test.txt
> C-x 3
> C-x b *scratch*
>
> # In new terminal
> emacsclient -c test.txt
>
> # I get a new window with the *scratch* buffer, but under Ubuntu 20.04
> the first emacsclient instance is on top also

I'm now sure what you mean by "the first emacsclient instance is on top
also"?

When I do this, I get a new Emacs frame with the *scratch* buffer
displayed -- is this what you're seeing?

And that seems like a bug.  The new emacsclient frame always pops up
with the buffer that is current in the other emacsclient frame instead
of the file/buffer you asked for.  (But the window with the requested
buffer in the old emacsclinet frame is selected.)

This only happens with a C-x 3 split; not with C-x 2 split.

Very odd.

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

bug#43645: 26.3; emacsclient -c does not open to correct window

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  43645@debbugs.gnu.org
> Date: Sun, 27 Sep 2020 18:02:02 +0200
> 
> I'm now sure what you mean by "the first emacsclient instance is on top
> also"?

My guess is that the frame created by the first emacsclient invocation
is on top (in the z-order) of that created by the second invocation.
That's probably a WM thing, though.

> When I do this, I get a new Emacs frame with the *scratch* buffer
> displayed

Does this happen even if the second invocation of emacsclient uses a
different file name, not the same test.txt as the first one?

bug#43645: 26.3; emacsclient -c does not open to correct window

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm now sure what you mean by "the first emacsclient instance is on top
>> also"?
>
> My guess is that the frame created by the first emacsclient invocation
> is on top (in the z-order) of that created by the second invocation.
> That's probably a WM thing, though.

Ah, right.  That does happen here, too, but I didn't notice because of
how my windows are arranged.

>> When I do this, I get a new Emacs frame with the *scratch* buffer
>> displayed
>
> Does this happen even if the second invocation of emacsclient uses a
> different file name, not the same test.txt as the first one?

No, if I say "emacsclient -c foo.txt", then a new frame is popped up
displaying the foo.txt buffer.

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

bug#43645: 26.3; emacsclient -c does not open to correct window

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bluetrack121@gmail.com,  43645@debbugs.gnu.org
> Date: Sun, 27 Sep 2020 18:21:27 +0200
> 
> >> When I do this, I get a new Emacs frame with the *scratch* buffer
> >> displayed
> >
> > Does this happen even if the second invocation of emacsclient uses a
> > different file name, not the same test.txt as the first one?
> 
> No, if I say "emacsclient -c foo.txt", then a new frame is popped up
> displaying the foo.txt buffer.

So I think (a) this is a corner and unimportant use case, and (b) it
probably has something to do with how we select a buffer to display
when 2 buffers are already on display and the user requests to see one
of them.

bug#43645: 26.3; emacsclient -c does not open to correct window

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So I think (a) this is a corner and unimportant use case, and (b) it
> probably has something to do with how we select a buffer to display
> when 2 buffers are already on display and the user requests to see one
> of them.

Yes.  And I was wrong -- the bug also appears in a C-x 2 split, not just
a C-x 3 split.

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

bug#43645: 26.3; emacsclient -c does not open to correct window

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bluetrack121@gmail.com,  43645@debbugs.gnu.org
> Date: Sun, 27 Sep 2020 18:44:20 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So I think (a) this is a corner and unimportant use case, and (b) it
> > probably has something to do with how we select a buffer to display
> > when 2 buffers are already on display and the user requests to see one
> > of them.
> 
> Yes.  And I was wrong -- the bug also appears in a C-x 2 split, not just
> a C-x 3 split.

Makes sense, because the two cases should be indistinguishable when
selecting a buffer to show is concerned.

bug#43645: 26.3; emacsclient -c does not open to correct window

[Lars Ingebrigtsen]

This patch fixes the problem, but I'm hesitating to apply it even if it
looks kinda-sorta "obviously correct": It changes the logic to only
check whether the buffer is displayed in the current frame, which makes
emacsclient -c work.  But why was the all-frame argument added?  It's
been there since at least the 90s...

I can't see any adverse affects on emacsclient -t either.

Anybody with any insight here?

diff --git a/lisp/server.el b/lisp/server.el
index 436a6ca0c7..f24f8d2b7c 100644
--- a/lisp/server.el
+++ b/lisp/server.el
@@ -1602,7 +1602,7 @@ server-switch-buffer
       ;; OK, we know next-buffer is live, let's display and select it.
       (if (functionp server-window)
 	  (funcall server-window next-buffer)
-	(let ((win (get-buffer-window next-buffer 0)))
+	(let ((win (get-buffer-window next-buffer)))
 	  (if (and win (not server-window))
 	      ;; The buffer is already displayed: just reuse the
 	      ;; window.  If FILEPOS is non-nil, use it to replace the

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

bug#43645: 26.3; emacsclient -c does not open to correct window

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 28 Sep 2020 15:16:16 +0200
> Cc: 43645@debbugs.gnu.org
> 
> This patch fixes the problem, but I'm hesitating to apply it even if it
> looks kinda-sorta "obviously correct": It changes the logic to only
> check whether the buffer is displayed in the current frame, which makes
> emacsclient -c work.  But why was the all-frame argument added?  It's
> been there since at least the 90s...
> 
> I can't see any adverse affects on emacsclient -t either.
> 
> Anybody with any insight here?
> 
> diff --git a/lisp/server.el b/lisp/server.el
> index 436a6ca0c7..f24f8d2b7c 100644
> --- a/lisp/server.el
> +++ b/lisp/server.el
> @@ -1602,7 +1602,7 @@ server-switch-buffer
>        ;; OK, we know next-buffer is live, let's display and select it.
>        (if (functionp server-window)
>  	  (funcall server-window next-buffer)
> -	(let ((win (get-buffer-window next-buffer 0)))
> +	(let ((win (get-buffer-window next-buffer)))
>  	  (if (and win (not server-window))
>  	      ;; The buffer is already displayed: just reuse the
>  	      ;; window.  If FILEPOS is non-nil, use it to replace the
> 

Martin, any comments on this?

Thanks.

bug#43645: 26.3; emacsclient -c does not open to correct window

[martin rudalics]

 >> diff --git a/lisp/server.el b/lisp/server.el
 >> index 436a6ca0c7..f24f8d2b7c 100644
 >> --- a/lisp/server.el
 >> +++ b/lisp/server.el
 >> @@ -1602,7 +1602,7 @@ server-switch-buffer
 >>         ;; OK, we know next-buffer is live, let's display and select it.
 >>         (if (functionp server-window)
 >>   	  (funcall server-window next-buffer)
 >> -	(let ((win (get-buffer-window next-buffer 0)))
 >> +	(let ((win (get-buffer-window next-buffer)))
 >>   	  (if (and win (not server-window))
 >>   	      ;; The buffer is already displayed: just reuse the
 >>   	      ;; window.  If FILEPOS is non-nil, use it to replace the
 >>
 >
 > Martin, any comments on this?

Wouldn't the "0" make sense when invoking emacsclient without an option
like -c or -t?  IIUC, in that case we should try to reuse some existing
visible or iconified window.  But ... I never use emacsclient.

martin

bug#43645: 26.3; emacsclient -c does not open to correct window

[Eli Zaretskii]

> Cc: bluetrack121@gmail.com, 43645@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 28 Sep 2020 17:02:13 +0200
> 
>  >> diff --git a/lisp/server.el b/lisp/server.el
>  >> index 436a6ca0c7..f24f8d2b7c 100644
>  >> --- a/lisp/server.el
>  >> +++ b/lisp/server.el
>  >> @@ -1602,7 +1602,7 @@ server-switch-buffer
>  >>         ;; OK, we know next-buffer is live, let's display and select it.
>  >>         (if (functionp server-window)
>  >>   	  (funcall server-window next-buffer)
>  >> -	(let ((win (get-buffer-window next-buffer 0)))
>  >> +	(let ((win (get-buffer-window next-buffer)))
>  >>   	  (if (and win (not server-window))
>  >>   	      ;; The buffer is already displayed: just reuse the
>  >>   	      ;; window.  If FILEPOS is non-nil, use it to replace the
>  >>
>  >
>  > Martin, any comments on this?
> 
> Wouldn't the "0" make sense when invoking emacsclient without an option
> like -c or -t?  IIUC, in that case we should try to reuse some existing
> visible or iconified window.  But ... I never use emacsclient.

Lars, can you try Martin's proposal and see if it solves the problem
without any adverse side effects on other use cases?

Thanks.

bug#43645: 26.3; emacsclient -c does not open to correct window

[Lars Ingebrigtsen]

martin rudalics <rudalics@gmx.at> writes:

>>> -	(let ((win (get-buffer-window next-buffer 0)))
>>> +	(let ((win (get-buffer-window next-buffer)))
>>>   	  (if (and win (not server-window))
>>>   	      ;; The buffer is already displayed: just reuse the
>>>   	      ;; window.  If FILEPOS is non-nil, use it to replace the
>>>
>>
>> Martin, any comments on this?
>
> Wouldn't the "0" make sense when invoking emacsclient without an option
> like -c or -t?  IIUC, in that case we should try to reuse some existing
> visible or iconified window.  But ... I never use emacsclient.

Hm, yes...   The behavioural change would be if you already have two
frames open, with the buffer showing in a window on frame A, but frame B
currently has focus, then "emacsclient test.txt" would pop up that
buffer in frame B, too.

So the 0 should be there in the "emacsclient test.txt" case, but not in
the "emacsclient -c test.txt" (and -t) cases.  I'll see if I can come up
with a fix...

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

bug#43645: 26.3; emacsclient -c does not open to correct window

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So the 0 should be there in the "emacsclient test.txt" case, but not in
> the "emacsclient -c test.txt" (and -t) cases.  I'll see if I can come up
> with a fix...

I'm not very familiar with this code at all, but I think I came up with
a pretty straightforward fix in Emacs 28 (that retains the old behaviour
for emacsclient without -c/-t.

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