From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#59976: ERC 5.4.1: erc-networks--id gets clobbered in erc server buffer on /query name conflict Date: Fri, 16 Dec 2022 07:17:18 -0800 Message-ID: <87r0wzgyyp.fsf__28762.427163177$1671203958$gmane$org@neverwas.me> References: <20221212000031.2f679e5e@malediction> <87pmcowuzv.fsf@neverwas.me> <20221212203508.3cd44bb6@malediction> <87o7s7qqut.fsf@neverwas.me> <87sfhgn45z.fsf@neverwas.me> <20221215232455.4a9c6677@malediction> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="966"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-erc@gnu.org, 59976-done@debbugs.gnu.org To: Mike Kazantsev Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 16 16:19:09 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p6CUO-000AWh-Jh for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Dec 2022 16:19:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6CU3-0006Lu-Qk; Fri, 16 Dec 2022 10:18:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6CTM-0006DW-Jj for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2022 10:18:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p6CTK-0007Is-NE for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2022 10:18:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p6CTK-0000kT-I7 for bug-gnu-emacs@gnu.org; Fri, 16 Dec 2022 10:18:02 -0500 Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Dec 2022 15:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 59976 X-GNU-PR-Package: emacs Mail-Followup-To: 59976@debbugs.gnu.org, jp@neverwas.me, mk.fraggod@gmail.com Original-Received: via spool by 59976-done@debbugs.gnu.org id=D59976.16712038552860 (code D ref 59976); Fri, 16 Dec 2022 15:18:02 +0000 Original-Received: (at 59976-done) by debbugs.gnu.org; 16 Dec 2022 15:17:35 +0000 Original-Received: from localhost ([127.0.0.1]:49947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6CSs-0000k4-Tv for submit@debbugs.gnu.org; Fri, 16 Dec 2022 10:17:35 -0500 Original-Received: from mail-108-mta53.mxroute.com ([136.175.108.53]:42079) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p6CSq-0000jx-6z for 59976-done@debbugs.gnu.org; Fri, 16 Dec 2022 10:17:33 -0500 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta53.mxroute.com (ZoneMTA) with ESMTPSA id 1851b82e6640001d7e.001 for <59976-done@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 16 Dec 2022 15:17:21 +0000 X-Zone-Loop: 5995d01034b423fdc7769f14627e1b3ef2fc606db00f X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZB8O13JFaToVzfmTdbmIzxeBm88Tl2Y9TAS60ridxZw=; b=NHjNnvzSr3Wz86LCVR6mxrE4Qq b5YGGq2jW2xHJGF7gNJqFhAFW3EhDtIg/Paqmp7rfcmST59W1JhDV/PNl+lnBCGmHVzU+Fhn2LvNe QuniZvMpYAFBYKR0+WDx+8bWLaq5LnzXU6ReGgkawCMGTMWhcy85zwpG/TE9AhDJbMsrTI7NwKQsT Wjlxz/4A7PtAyL4iU+kfHge2/3jTvR0X8NDFc1qc1oGhNX/zWRF+RMKnSGUSdSdxy+1pvla+HjudA ARINtAthoJs0EdragzseFUZrCOXT0xfJBUI7UqVDgbp2NmKaF47FXeZzKRXINozvzKZWsS9OaBnbE tBQmfcRg==; In-Reply-To: <20221215232455.4a9c6677@malediction> (Mike Kazantsev's message of "Thu, 15 Dec 2022 23:24:55 +0500") X-Authenticated-Id: masked@neverwas.me X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:251214 Archived-At: Mike Kazantsev writes: > On Thu, 15 Dec 2022 06:16:08 -0800 > "J.P." wrote: > >> Anyhow, I have attempted to address this in the attached patch. If you >> or anyone out there is willing, please install it locally atop the >> current lisp/erc subtree on the emacs-29 branch and see if you can break >> it. Thanks in advance! > > I think you indeed found the same thing I was thinking of and fixed it, t= hanks. > > You mentioned connection process and how ID is being set in the previous > message, which indeed didn't seem to be same issues as I've tried to desc= ribe > (not clearly enough). Well, I've long been in the terrible habit of just saying "connection" when I really mean "logical IRC connection" and not the actual network process. But sometimes I mean both or one then the other, which is obviously insane but likely what happened here (so please just take whatever I said with a grain of salt). > So thought to make a quick mockup of an IRC server and then send it, > with precise commands to run from ERC to reproduce exact problem, > as well actual output from that variable-change-tracking (which shows > how/when ID gets erased after successful connection, and only after > triggering conflicting query-buffer creation). > > Haven't gotten around to do it yet though, but pretty sure you found > and fixed same exact issue in 0001-Fix-some-naming-issues-*.patch here, > so there should no longer be any need to do it. > > I've just tested removing my custom ID-setting advices/code, using :id > instead, as well as reproducing that exact query-buffer-name conflict, > and it all works without any issues that I can see. > So will use that instead of local code hacks and won't need to worry > about making server-buffer names unique/distinct. Nice! > One small thing I've noticed about :id is that it has separate "Network > Identifier" section in "Connecting" info page, which doesn't seem to be l= inked > directly in its description - not sure if intentional, or maybe an oversi= ght: > > When present, ID should be an opaque object for identifying the > connection unequivocally. (In most cases, this would be a string or a > symbol composed of letters from the Latin alphabet.) This option is > generally unneeded, however. See info node =E2=80=98(erc) Connecting= =E2=80=99 for use > cases. Not available interactively. Good catch. > Come to think of it, I'd probably also add the most obvious effect of :id > for naming the server buffer, i.e. something like this: > > When present, ID should be an opaque object for identifying the connect= ion > unequivocally, and will correspond to name of the created erc server bu= ffer > after connection. ... > > Can probably be phrased better, but since main effect of "(erc ...)" comm= and is > creating that server buffer, what it will be named seem to be an importan= t detail > (if only for finding it afterwards). > > [...] > > In fact, I think allowing for naming server buffers how you want them > to be named with one easy and reasonably-obvious option should probably > be most prominent thing about it: > > https://e.var.nz/scr-20221215233955.jpg > > (example of using :id for all networks, in contrast to earlier > inconsistent not-entirely-local naming) Agreed. Thanks. I have attempted to change it to something along the lines of what you've suggested. Hopefully it's passable. > Pretty sure patches you've attached address main issue I wanted to raise > (as well as couple other issues). > > Thanks again for doing all the work here. My pleasure. I've added the changes to Emacs 29, so they should appear on HEAD as well, shortly. > And apologies for not being able to articulate main problem more clearly. > Given how simple IRC is, should've definitely attached some easy-to-run > protocol example to reproduce it in the first place (maybe as .eld test-c= ase), > instead of meandering description. Nah. Your input has made all the difference. Bug reports, especially good ones like this, are terribly undervalued as contributions, IMO. Please consider contributing to ERC (in any form) again in the future. Until next time!