From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mike Kazantsev 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: Thu, 15 Dec 2022 23:24:55 +0500 Message-ID: <20221215232455.4a9c6677__45574.3953398027$1671128785$gmane$org@malediction> References: <20221212000031.2f679e5e@malediction> <87pmcowuzv.fsf@neverwas.me> <20221212203508.3cd44bb6@malediction> <87o7s7qqut.fsf@neverwas.me> <87sfhgn45z.fsf@neverwas.me> 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="23587"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59976@debbugs.gnu.org, emacs-erc@gnu.org To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 15 19:26:18 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 1p5svy-0005t9-6w for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Dec 2022 19:26:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p5svp-0002Mh-Hr; Thu, 15 Dec 2022 13:26:09 -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 1p5svi-0002MN-Uh for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2022 13:26:03 -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 1p5svi-0000u4-NC for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2022 13:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p5svi-000861-7U for bug-gnu-emacs@gnu.org; Thu, 15 Dec 2022 13:26:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Mike Kazantsev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Dec 2022 18:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59976 X-GNU-PR-Package: emacs Original-Received: via spool by 59976-submit@debbugs.gnu.org id=B59976.167112871031095 (code B ref 59976); Thu, 15 Dec 2022 18:26:02 +0000 Original-Received: (at 59976) by debbugs.gnu.org; 15 Dec 2022 18:25:10 +0000 Original-Received: from localhost ([127.0.0.1]:44181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5sus-00085T-BA for submit@debbugs.gnu.org; Thu, 15 Dec 2022 13:25:10 -0500 Original-Received: from mail-lf1-f45.google.com ([209.85.167.45]:45758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p5sun-000851-PS for 59976@debbugs.gnu.org; Thu, 15 Dec 2022 13:25:09 -0500 Original-Received: by mail-lf1-f45.google.com with SMTP id p36so16963765lfa.12 for <59976@debbugs.gnu.org>; Thu, 15 Dec 2022 10:25:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=SQihUH2WeY4W9pmTg1kYlH4qAslaPWBpXwrsZm1Y0yA=; b=p+gqqrCwsqneKi1SBFJhcIQ8XudAx9oxN50Ur1r1r1R8WRMVCvpkrWSTMvjTqcWUcK JkYKz17i9WwKAT8rjwbIyHopiY3GbV/BA5NcScBEwxpPCl2iV8GzkjLLQd4pcqhRTbfB fkS8y/T8xwWE9ysSEjFjbORtODIjw82O2VT4dT2FBVetgSUnfp4zr+Yf9hi/6T2+RyS6 rXj5az/ohUswRXHj3psBYuOGheAs7Hv0Xo9nZNq1fwDdBXUVbShrG7z6jKCVd1/Epewm QpJH3zcjEgiXcSsyLK6uhSc905z1vUbfTtPKgOl7qCvA8pjqbghBGbdMGhpuSPTkFkil 9mNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=SQihUH2WeY4W9pmTg1kYlH4qAslaPWBpXwrsZm1Y0yA=; b=qDsbTDZW/JmnJF+r+6kpQE8AnR4GX65MrOGOxOr6Ll0YUc0+Itz+HuiFIj246H4y69 2VBI2zai418wjG5E5LHp+g5PMU9e5mMv4E6uALMbTj4ZFxZJtSm41p1o76nmWaFMvMQb 5LMSDVpkp7zb15yMnS5a3rhcK1Spyy6jJVG938dNr/OS3GCu8HUnZcP/RkL6InEqvykZ p7sqk6mGKbKfczR+7zEpf/pllqET8miLpsJFyoTP32ymZYIgA9zGcC3aFXVrE6ilMQy0 c4dOpknWk7T8DpIsi8foJ0G2V0RCdsuYtRiYRHd6f5tpY+u8b27zH0J75p6UUvu3tiIH ZEyg== X-Gm-Message-State: ANoB5pnaA7vsdwpVW4JImYUKRAJaV4Dm4Scn2S1iFtC4EpZHAP4ngtUX OGxikRMNBVYyMWBRs0C8xE8= X-Google-Smtp-Source: AA0mqf6dqfqO2107d18LRWTuAylXL8ne55Mt51wjxdyG4+d+kjkNCCAa57CVJB60tsrwm6YAA9wv9g== X-Received: by 2002:a05:6512:3691:b0:4b6:fddc:1fcd with SMTP id d17-20020a056512369100b004b6fddc1fcdmr3267042lfs.23.1671128699583; Thu, 15 Dec 2022 10:24:59 -0800 (PST) Original-Received: from malediction ([46.48.96.28]) by smtp.gmail.com with ESMTPSA id y11-20020a05651c106b00b00279ee47099dsm4342ljm.116.2022.12.15.10.24.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Dec 2022 10:24:58 -0800 (PST) In-Reply-To: <87sfhgn45z.fsf@neverwas.me> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.35; x86_64-pc-linux-gnu) 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:251133 Archived-At: On Thu, 15 Dec 2022 06:16:08 -0800 "J.P." wrote: > "J.P." writes: >=20 > >>> Unfortunately, the best we can do for ERC 5.5 (Emacs 29) is to mention > >>> somewhere, like in (info "(erc) Network Identifier"), that users real= ly > >>> worried about this issue should choose an `:id' containing characters > >>> disallowed in nicks by their network (or just something improbable and > >>> unlikely to be guessed). But, hopefully, we can address this in a more > >>> DWIM-like fashion in an upcoming ELPA release, such as ERC 5.6. =20 > >> > >> Hopefully won't be an issue for most people, although it might be not > >> that uncommon for this kind of service/bot/proxy ircd's to also use > >> their name for messaging user with any kind of service-related info/is= sues. =20 > > > > Hm, right. That's good to know. I think the key for now is to make > > people aware that they should assign an ID or modify > > `erc-networks-alist' if they find themselves in a similar boat. Most > > folks just connecting to a public network should be safe because those > > NETWORKs are mostly titlecase and/or contain a dot. But, in the long > > run, I'd definitely like the default behavior to account for this > > possibility. =20 >=20 > Actually, an egregious oversight has come to light that makes this a > more general (and more pressing) matter relevant to Emacs 29. Currently, > renaming queries fails if *any* buffer, even a non-ERC buffer, exists > whose name matches that of the target in question. And, AFAICT, no > amount of :id or options twiddling can serve as a workaround. (If this > is what you've been getting at this whole time, then apologies: I'm > rather thick headed, if you haven't noticed.) >=20 > 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, tha= nks. 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 descri= be (not clearly enough). 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. 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 lin= ked directly in its description - not sure if intentional, or maybe an oversigh= t: 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. 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 connection unequivocally, and will correspond to name of the created erc server buff= er after connection. ... Can probably be phrased better, but since main effect of "(erc ...)" comman= d is creating that server buffer, what it will be named seem to be an important = detail (if only for finding it afterwards). 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. 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-cas= e), instead of meandering description. --=20 Mike Kazantsev // fraggod.net