GNU bug report logs - #40121
27.0.90; ERC incorrectly reuses single buffer for channels of same name on multiple networks

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40121 in the body.
You can then email your comments to 40121 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.90; ERC incorrectly reuses single buffer for channels of same
 name on multiple networks
Date: Wed, 18 Mar 2020 11:08:59 -0500

I'm able to get two channels of the same name sharing a single buffer.
I was hunting for this feature once upon a time but I *swear* I didn't
do *anything* :)

1. emacs -Q
  On windows, so I used: D:\projects>c:\emacs-27.0.90\x86_64\bin\runemacs.exe -Q

2. M-x erc RET
  Connect to an IRC network such as freenode.
  Expect: Connection occurs succcessfully; server buffer opens)

3. /join #mytestchannel RET
  Do this in the server buffer after connecting.
  Expect: Channel joined successfully, channel buffer opens.
  Actual: OK

4. M-x erc RET
  Connect to a second IRC network such as efnet
  Expect: Connection occurs succcessfully; server buffer opens)
  Actual: OK

3. /join #mytestchannel RET
  Do this in the new/second server buffer after both network connections
  are successful.
  Expect: Channel joined successfully, new channel buffer opens.
  Actual: NOT OK

When I join a second channel of the same name on a different network,
rather than create a new buffer and switch to it, ERC is reusing the
buffer created for the channel on the first network.  I see a
consolidated feed of messages sent from either network's channel and the
mode line for this "shared" buffer changes to reflect whichever network
last sent traffic to it.

Before confirming I can reproduce in -Q and creating this report I left
my client running and connected to both channels for a couple of days.
ERC was stable this time.  In fact, if I had some way to select which
network's channel I was sending too (and if I had any control over it
happening) this might be a cool feature.  As it is messages are sent to
whichever network last wrote to the buffer.

Using the following expression in M-: with the "shared" buffer selected
I can see that the erc-session-server (which I think of as "IRC network
server") does change as incoming traffic causes each respective network
to "take over" the buffer.

;; list erc buffers and their network
(mapconcat
  (lambda(b)
    (with-current-buffer b
      (format "%s => %s\n" b erc-session-server)))
  (erc-all-buffer-names) " ")

I had some additional issues with nickname autocomplete that may be
related but I've not troubled to research these at all yet.

I'll share additional detail or a patch when/if I develop any.

Thank you!


In GNU Emacs 27.0.90 (build 1, x86_64-w64-mingw32)
 of 2020-03-01 built on CIRROCUMULUS
Repository revision: c5f255d68156926923232b1edadf50faac527861
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Home (v10.0.1909.18363.720)

Recent messages:
Logging in as `mplsCorwin'...
Logging in as ‘mplsCorwin’... done
Connecting to irc.perl.org:6667...
Logging in as `corwin'...
Logging in without password
Logging in as ‘corwin’... done
Making completion list...
Commands: d, s, x, u; f, o, 1, 2, m, v; ~, %; q to quit; ? for help.
Mark set
Making completion list...

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Buffer Menu

Minor modes in effect:
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  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
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils erc-list erc-menu
easymenu erc-join erc-ring erc-networks erc-pcomplete time-date
pcomplete comint ansi-color ring erc-track erc-match erc-button
browse-url wid-edit erc-fill erc-stamp erc-netsplit erc-goodies erc
erc-backend erc-compat format-spec auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs cl-loaddefs cl-lib password-cache json subr-x map
seq byte-opt gv bytecomp byte-compile cconv thingatpt pp erc-loaddefs
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 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 w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 87033 18275)
 (symbols 48 9967 1)
 (strings 32 28608 1896)
 (string-bytes 1 880312)
 (vectors 16 15638)
 (vector-slots 8 185817 12702)
 (floats 8 42 320)
 (intervals 56 876 280)
 (buffers 1000 16))

Message #8 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Brubeck Unhammer <unhammer <at> fsfe.org>
To: Corwin Brust <corwin <at> bru.st>
Cc: 40121 <at> debbugs.gnu.org
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Mon, 22 Jun 2020 15:33:59 +0200

I have bisected. The regression seems to have been introduced in commit
cdefc045893a7fed57856ac385ab41c71f61c09f
"Fix problem with erc buffer renames after reconnect"
which was supposed to solve
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30639

Reverting that commit fixes it for me.

Message #11 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Brubeck Unhammer <unhammer <at> fsfe.org>
Cc: 40121 <at> debbugs.gnu.org, Corwin Brust <corwin <at> bru.st>
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Sun, 02 Aug 2020 09:44:02 +0200

Kevin Brubeck Unhammer <unhammer <at> fsfe.org> writes:

> I have bisected. The regression seems to have been introduced in commit
> cdefc045893a7fed57856ac385ab41c71f61c09f
> "Fix problem with erc buffer renames after reconnect"
> which was supposed to solve
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30639

This should now be fixed in Emacs 28.1.

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

Message #18 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Brubeck Unhammer <unhammer <at> fsfe.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40121 <at> debbugs.gnu.org, Corwin Brust <corwin <at> bru.st>
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Wed, 05 Aug 2020 11:00:25 +0200

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> čálii:

> Kevin Brubeck Unhammer <unhammer <at> fsfe.org> writes:
>
>> I have bisected. The regression seems to have been introduced in commit
>> cdefc045893a7fed57856ac385ab41c71f61c09f
>> "Fix problem with erc buffer renames after reconnect"
>> which was supposed to solve
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30639
>
> This should now be fixed in Emacs 28.1.

There's still a bug when there's two networks on the same server:port.

But the fix is simple, just an `(and target …)` around the "Channel
buffer" case, like

                   ;; Channel buffer; check that it's from the right server.
                   (and target
                        (with-current-buffer (get-buffer candidate)
                          (and (string= erc-session-server server)
                               (erc-port-equal erc-session-port port))))

I connect to several networks on the same server:port (my weechat
instance). Without the `and target` check it'll reuse the server buffer
from network1 when connecting to network2.

[signature.asc (application/pgp-signature, inline)]

Message #21 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Kevin Brubeck Unhammer <unhammer <at> fsfe.org>
Cc: 40121 <at> debbugs.gnu.org, Corwin Brust <corwin <at> bru.st>
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Wed, 05 Aug 2020 11:14:18 +0200

Kevin Brubeck Unhammer <unhammer <at> fsfe.org> writes:

> There's still a bug when there's two networks on the same server:port.
>
> But the fix is simple, just an `(and target …)` around the "Channel
> buffer" case, like
>
>                    ;; Channel buffer; check that it's from the right server.
>                    (and target
>                         (with-current-buffer (get-buffer candidate)
>                           (and (string= erc-session-server server)
>                                (erc-port-equal erc-session-port port))))
>
> I connect to several networks on the same server:port (my weechat
> instance). Without the `and target` check it'll reuse the server buffer
> from network1 when connecting to network2.

Ah, I see.  I didn't even know that was possible.  :-)

I've now applied your fix to Emacs 28.

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

Message #24 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Kevin Brubeck Unhammer <unhammer <at> fsfe.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 40121 <at> debbugs.gnu.org
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Wed, 05 Aug 2020 12:37:12 +0200

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen <larsi <at> gnus.org> čálii:

> Kevin Brubeck Unhammer <unhammer <at> fsfe.org> writes:
>
>> There's still a bug when there's two networks on the same server:port.
>>
>> But the fix is simple, just an `(and target …)` around the "Channel
>> buffer" case, like
>>
>>                    ;; Channel buffer; check that it's from the right server.
>>                    (and target
>>                         (with-current-buffer (get-buffer candidate)
>>                           (and (string= erc-session-server server)
>>                                (erc-port-equal erc-session-port port))))
>>
>> I connect to several networks on the same server:port (my weechat
>> instance). Without the `and target` check it'll reuse the server buffer
>> from network1 when connecting to network2.
>
> Ah, I see.  I didn't even know that was possible.  :-)
>
> I've now applied your fix to Emacs 28.

Thanks! :)

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: "Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com>
To: 40121 <at> debbugs.gnu.org
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Tue, 04 Aug 2020 22:34:24 -0400

I submitted a patch that should fix this problem completely.

--
Mingde (Matthew) Zeng

Message #30 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com>
Cc: 40121 <at> debbugs.gnu.org
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Wed, 05 Aug 2020 14:53:13 +0200

"Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com> writes:

> I submitted a patch that should fix this problem completely.

Did you send it to 40121 <at> debbugs.gnu.org?  It's nice to have the patches
in the bug tracker.

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

Message #33 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Corwin Brust <corwin <at> bru.st>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Mingde \(Matthew\) Zeng" <matthewzmd <at> gmail.com>, 40121 <at> debbugs.gnu.org
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Wed, 5 Aug 2020 08:09:03 -0500

[Message part 1 (text/plain, inline)]

Hi!

On Wed, Aug 5, 2020, 7:54 AM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> "Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com> writes:
>
> > I submitted a patch that should fix this problem completely.
>
> Did you send it to 40121 <at> debbugs.gnu.org?  It's nice to have the patches
> in the bug tracker.
>

I really appreciate everyone's work on this; I will look and help confirm
next week when I am home from vacation.

>

[Message part 2 (text/html, inline)]

Message #36 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Amin Bandali <bandali <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: "Mingde \(Matthew\) Zeng" <matthewzmd <at> gmail.com>, 40121 <at> debbugs.gnu.org
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Wed, 05 Aug 2020 09:13:28 -0400

[Message part 1 (text/plain, inline)]

Lars Ingebrigtsen writes:

> "Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com> writes:
>
>> I submitted a patch that should fix this problem completely.
>
> Did you send it to 40121 <at> debbugs.gnu.org?  It's nice to have the patches
> in the bug tracker.

He'd sent it to emacs-devel, after some bit of feedback me and others
had given him about his previous patches, also on emacs-devel.

https://lists.gnu.org/archive/html/emacs-devel/2020-08/msg00084.html

I'll let the two of you coordinate with each other since you are both
working on the same issue.  For future cases, let us try to keep an eye
both on the tracker and on the emacs-devel list before sending a patch
or pushing a change, to help make sure we don't do duplicate work or
make simultaneous conflicting changes where one contributor tries to
chase a moving target. :-)

Thanks.

[signature.asc (application/pgp-signature, inline)]

Message #39 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Amin Bandali <bandali <at> gnu.org>
Cc: "Mingde \(Matthew\) Zeng" <matthewzmd <at> gmail.com>, 40121 <at> debbugs.gnu.org
Subject: Re: bug#40121: 27.0.90; ERC incorrectly reuses single buffer for
 channels of same name on multiple networks
Date: Wed, 05 Aug 2020 15:26:41 +0200

Amin Bandali <bandali <at> gnu.org> writes:

> I'll let the two of you coordinate with each other since you are both
> working on the same issue.  For future cases, let us try to keep an eye
> both on the tracker and on the emacs-devel list before sending a patch
> or pushing a change, to help make sure we don't do duplicate work or
> make simultaneous conflicting changes where one contributor tries to
> chase a moving target. :-)

Yeah, sorry about that.

And there was another patch applied to the function earlier today.  :-/

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

Message #42 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: "Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com>
To: 40121 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Cc: larsi <at> gnus.org
Subject: [PATCHv2] erc: fix erc-reuse-buffers behavior
Date: Tue, 11 Aug 2020 14:53:48 -0400

By the definition of erc-reuse-buffers, if non-nil it should create a
new buffer when joining channels with same names on different
servers. The current behavior of erc-reuse-buffers is:
1. when non-nil, it will always reuse the same channel buffer,
resulting in server A's channel gets reconnected to the channel with
the same name of server B.
2. when nil, the buffer-name of the joined channel is
'#channel/server'. However if one tries to '/join #channel' from the
server buffer, it creates a new empty buffer with buffer-name
'#channel', instead of opening the already-joined channel buffer.

This bug is partly documented in bug#40121.

* lisp/erc/erc.el (erc-generate-new-buffer-name): fixes behavior 1,
also determines if the '#channel/server' buffer already exists
and will reuse that buffer when joining on the same
server. Additionally when creating a new buffer with
'#channel/serverB', the existing buffer '#channel' on 'severA' will be
renamed to '#channel/serverA' for the sake of consistency.

(erc-cmd-JOIN): with some refactoring, it ensures
the joined channel buffer is selected and thereby fixes the second
behavior.

* lisp/erc/erc-join.el (erc-autojoin-channels): the logic is
simplified ensuring that when autojoining channels specified in
erc-autojoin-channels-alist, if there exists an erc buffer with the
same channel name but a different server, it will create a new buffer
to join the channel. The current logic is very weak that will skip
joining same channel on different servers altogether.
---
 lisp/erc/erc-join.el | 22 ++++++------
 lisp/erc/erc.el      | 85 +++++++++++++++++++++++++-------------------
 2 files changed, 61 insertions(+), 46 deletions(-)

diff --git a/lisp/erc/erc-join.el b/lisp/erc/erc-join.el
index e4faf6bd79..79c111082f 100644
--- a/lisp/erc/erc-join.el
+++ b/lisp/erc/erc-join.el
@@ -153,18 +153,20 @@ This function is run from `erc-nickserv-identified-hook'."
 			      'erc-autojoin-channels-delayed
 			      server nick (current-buffer))))
     ;; `erc-autojoin-timing' is `connect':
-    (dolist (l erc-autojoin-channels-alist)
-      (when (string-match (car l) server)
-	(let ((server (or erc-session-server erc-server-announced-name)))
+    (let ((server (or erc-session-server erc-server-announced-name)))
+      (dolist (l erc-autojoin-channels-alist)
+        (when (string-match-p (car l) server)
 	  (dolist (chan (cdr l))
-	    (let ((buffer (erc-get-buffer chan)))
-	      ;; Only auto-join the channels that we aren't already in
-	      ;; using a different nick.
+	    (let ((buffer
+                   (car (erc-buffer-filter
+                         (lambda ()
+                           (let ((current (erc-default-target)))
+                             (and (stringp current)
+                                  (string-match-p (car l)
+                                                  (or erc-session-server erc-server-announced-name))
+                                  (string-equal (erc-downcase chan)
+                                                (erc-downcase current)))))))))
 	      (when (or (not buffer)
-			;; If the same channel is joined on another
-			;; server the best-effort is to just join
-			(not (string-match (car l)
-					   (process-name erc-server-process)))
 			(not (with-current-buffer buffer
 			       (erc-server-process-alive))))
 		(erc-server-join-channel server chan))))))))
diff --git a/lisp/erc/erc.el b/lisp/erc/erc.el
index 404a4c0997..41d7516fbb 100644
--- a/lisp/erc/erc.el
+++ b/lisp/erc/erc.el
@@ -1608,36 +1608,47 @@ symbol, it may have these values:
 (defun erc-generate-new-buffer-name (server port target)
   "Create a new buffer name based on the arguments."
   (when (numberp port) (setq port (number-to-string port)))
-  (let ((buf-name (or target
-                      (or (let ((name (concat server ":" port)))
-                            (when (> (length name) 1)
-                              name))
-                          ;; This fallback should in fact never happen
-                          "*erc-server-buffer*")))
-        buffer-name)
+  (let* ((buf-name (or target
+                       (let ((name (concat server ":" port)))
+                         (when (> (length name) 1)
+                           name))
+                       ;; This fallback should in fact never happen.
+                       "*erc-server-buffer*"))
+         (full-buf-name (concat buf-name "/" server))
+         (dup-buf-name (buffer-name (car (erc-channel-list nil))))
+         buffer-name)
     ;; Reuse existing buffers, but not if the buffer is a connected server
     ;; buffer and not if its associated with a different server than the
     ;; current ERC buffer.
-    ;; if buf-name is taken by a different connection (or by something !erc)
-    ;; then see if "buf-name/server" meets the same criteria
-    (dolist (candidate (list buf-name (concat buf-name "/" server)))
-      (if (and (not buffer-name)
-               erc-reuse-buffers
-               (or (not (get-buffer candidate))
-                   ;; Looking for a server buffer, so there's no target.
-                   (and (not target)
-                        (with-current-buffer (get-buffer candidate)
-                          (and (erc-server-buffer-p)
-                               (not (erc-server-process-alive)))))
-                   ;; Channel buffer; check that it's from the right server.
-                   (and target
-                        (with-current-buffer (get-buffer candidate)
-                          (and (string= erc-session-server server)
-                               (erc-port-equal erc-session-port port))))))
-          (setq buffer-name candidate)))
-    ;; if buffer-name is unset, neither candidate worked out for us,
+    ;; If buf-name is taken by a different connection (or by something !erc)
+    ;; then see if "buf-name/server" meets the same criteria.
+    (if (and dup-buf-name (string-match-p (concat buf-name "/") dup-buf-name))
+        (setq buffer-name full-buf-name) ; ERC buffer with full name already exists.
+      (dolist (candidate (list buf-name full-buf-name))
+        (if (and (not buffer-name)
+                 erc-reuse-buffers
+                 (or (not (get-buffer candidate))
+                     ;; Looking for a server buffer, so there's no target.
+                     (and (not target)
+                          (with-current-buffer (get-buffer candidate)
+                            (and (erc-server-buffer-p)
+                                 (not (erc-server-process-alive)))))
+                     ;; Channel buffer; check that it's from the right server.
+                     (and target
+                          (with-current-buffer (get-buffer candidate)
+                            (and (string= erc-session-server server)
+                                 (erc-port-equal erc-session-port port))))))
+            (setq buffer-name candidate)
+          (when (and (not buffer-name) (get-buffer buf-name) erc-reuse-buffers)
+            ;; A new buffer will be created with the name buf-name/server, rename
+            ;; the existing name-duplicated buffer with the same format as well.
+            (with-current-buffer (get-buffer buf-name)
+              (when (derived-mode-p 'erc-mode) ; ensure it's an erc buffer
+                (rename-buffer
+                 (concat buf-name "/" (or erc-session-server erc-server-announced-name)))))))))
+    ;; If buffer-name is unset, neither candidate worked out for us,
     ;; fallback to the old <N> uniquification method:
-    (or buffer-name (generate-new-buffer-name (concat buf-name "/" server)))))
+    (or buffer-name (generate-new-buffer-name full-buf-name))))

 (defun erc-get-buffer-create (server port target)
   "Create a new buffer based on the arguments."
@@ -3153,16 +3164,18 @@ were most recently invited.  See also `invitation'."
       (setq chnl (erc-ensure-channel-name channel)))
     (when chnl
       ;; Prevent double joining of same channel on same server.
-      (let ((joined-channels
-             (mapcar #'(lambda (chanbuf)
-                         (with-current-buffer chanbuf (erc-default-target)))
-                     (erc-channel-list erc-server-process))))
-        (if (erc-member-ignore-case chnl joined-channels)
-            (switch-to-buffer (car (erc-member-ignore-case chnl
-                                                           joined-channels)))
-	  (let ((server (with-current-buffer (process-buffer erc-server-process)
-			  (or erc-session-server erc-server-announced-name))))
-	    (erc-server-join-channel server chnl key))))))
+      (let* ((joined-channels
+              (mapcar #'(lambda (chanbuf)
+                          (with-current-buffer chanbuf (erc-default-target)))
+                      (erc-channel-list erc-server-process)))
+             (server (with-current-buffer (process-buffer erc-server-process)
+		       (or erc-session-server erc-server-announced-name)))
+             (chnl-name (car (erc-member-ignore-case chnl joined-channels))))
+        (if chnl-name
+            (switch-to-buffer (if (get-buffer chnl-name)
+                                  chnl-name
+                                (concat chnl-name "/" server)))
+	  (erc-server-join-channel server chnl key)))))
   t)

 (defalias 'erc-cmd-CHANNEL 'erc-cmd-JOIN)
--
2.27.0

Message #45 received at 40121 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com>
Cc: 40121 <at> debbugs.gnu.org
Subject: Re: [PATCHv2] erc: fix erc-reuse-buffers behavior
Date: Wed, 12 Aug 2020 13:10:01 +0200

"Mingde (Matthew) Zeng" <matthewzmd <at> gmail.com> writes:

> By the definition of erc-reuse-buffers, if non-nil it should create a
> new buffer when joining channels with same names on different
> servers. The current behavior of erc-reuse-buffers is:
> 1. when non-nil, it will always reuse the same channel buffer,
> resulting in server A's channel gets reconnected to the channel with
> the same name of server B.
> 2. when nil, the buffer-name of the joined channel is
> '#channel/server'. However if one tries to '/join #channel' from the
> server buffer, it creates a new empty buffer with buffer-name
> '#channel', instead of opening the already-joined channel buffer.

Thanks; applied to Emacs 28.

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

Previous Next

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