GNU bug report logs - #43645
26.3; emacsclient -c does not open to correct window

Previous Next

Package: emacs;

Reported by: Blue track <bluetrack121 <at> gmail.com>

Date: Sun, 27 Sep 2020 09:43:02 UTC

Severity: normal

Tags: fixed

Found in version 26.3

Fixed in version 28.1

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: bluetrack121 <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, 43645 <at> debbugs.gnu.org
Subject: bug#43645: 26.3; emacsclient -c does not open to correct window
Date: Tue, 29 Sep 2020 16:09:42 +0200
martin rudalics <rudalics <at> 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




This bug report was last modified 4 years and 237 days ago.

Previous Next


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