From: Kevin Brubeck Unhammer <unhammer@fsfe.org>
To: John Goerzen <jgoerzen@complete.org>
Cc: 30639@debbugs.gnu.org
Subject: bug#30639: 25.1; ERC buffer name not unique, broken on reconnect [patch]
Date: Wed, 24 Jun 2020 11:12:35 +0200 [thread overview]
Message-ID: <87o8p8g73w.fsf@fsfe.org> (raw)
In-Reply-To: <877eqyrv80.fsf@complete.org> (John Goerzen's message of "Tue, 27 Feb 2018 15:15:30 -0600")
Hi,
This commit caused a regression:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40121
cdefc045893a7fed57856ac385ab41c71f61c09f makes buffer #hello be used for
*both* networks instead of #hello<2> created on the next network. And
not just that, the other buffers on the same network will get their
network changed (so if #goodbye was on network1, and you connect to
network2 and join #hello there, #goodbye will say it's on network2).
I haven't looked into doing this change correctly yet, but reverting it
at least makes ERC work again for me.
best regards,
Kevin Brubeck Unhammer
John Goerzen <jgoerzen@complete.org> čálii:
> Hi,
>
> Over at https://www.emacswiki.org/emacs/ErcBugs, there is a description
> as follows:
>
> "When you're in two channels with the same name, e.g. #hello, on
> different networks, the buffers are called #hello and #hello<2>. Now, if
> you temporarily lose your connection (e.g. unplug the network cable and
> plug it back in) and ERC reconnects, #hello<2> will not be re-used, but
> instead #hello<3> will be created."
>
> I have observed this. This all goes back to a bug in
> erc/erc.el:erc-generate-new-buffer-name
>
> The comments in the function as given are reasonable, but the logic
> differs. In particular, the test in the dolist always fails when
> (get-buffer candidate) is nil; that is, the test always fails when the
> buffer does not already exist. This causes the test to drop through to
> the section at the bottom every time, which results not only in the
> server appending logic never being used, but also in the concatenation
> of /server never being attempted.
>
> Here is a working replacement:
>
> (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)
> ;; 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))
> (or target
> (with-current-buffer (get-buffer candidate)
> (and (erc-server-buffer-p)
> (not (erc-server-process-alive)))))
> (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,
> ;; fallback to the old <N> uniquification method:
> (or buffer-name (generate-new-buffer-name (concat buf-name "/" server))) ))
>
>
> In GNU Emacs 25.1.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
> of 2017-09-15, modified by Debian built on trouble
> Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
> System Description: Debian GNU/Linux 9.3 (stretch)
>
> 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/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
> --with-sound=alsa --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/emacs25:/etc/emacs:/usr/local/share/emacs/25.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/25.1/site-lisp:/usr/share/emacs/site-lisp
> --with-sound=alsa --with-x=yes --with-x-toolkit=gtk3
> --with-toolkit-scroll-bars 'CFLAGS=-g -O2
> -fdebug-prefix-map=/build/emacs25-wN2qS3/emacs25-25.1+1=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
> -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'
>
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
> NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11
>
> Important settings:
> value of $LANG: en_US.utf8
> locale-coding-system: utf-8-unix
>
> Major mode: mu4e:main
>
>
>
>
>
prev parent reply other threads:[~2020-06-24 9:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-27 21:15 bug#30639: 25.1; ERC buffer name not unique, broken on reconnect [patch] John Goerzen
2018-04-14 18:11 ` Lars Ingebrigtsen
2020-06-24 9:12 ` Kevin Brubeck Unhammer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87o8p8g73w.fsf@fsfe.org \
--to=unhammer@fsfe.org \
--cc=30639@debbugs.gnu.org \
--cc=jgoerzen@complete.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).