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: Mon, 12 Dec 2022 20:35:08 +0500 Message-ID: <20221212203508.3cd44bb6__49283.8849009544$1670859400$gmane$org@malediction> References: <20221212000031.2f679e5e@malediction> <87pmcowuzv.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="3587"; 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 Mon Dec 12 16:36:32 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 1p4kr0-0000fq-Pp for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 12 Dec 2022 16:36:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4kqm-0000qH-VU; Mon, 12 Dec 2022 10:36:17 -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 1p4kqa-0000n5-8k for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 10:36:06 -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 1p4kqY-0006K5-7R for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 10:36:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p4kqY-0008JR-37 for bug-gnu-emacs@gnu.org; Mon, 12 Dec 2022 10:36: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: Mon, 12 Dec 2022 15:36: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.167085932031917 (code B ref 59976); Mon, 12 Dec 2022 15:36:02 +0000 Original-Received: (at 59976) by debbugs.gnu.org; 12 Dec 2022 15:35:20 +0000 Original-Received: from localhost ([127.0.0.1]:53655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4kpr-0008Ij-9y for submit@debbugs.gnu.org; Mon, 12 Dec 2022 10:35:20 -0500 Original-Received: from mail-lj1-f172.google.com ([209.85.208.172]:33711) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p4kpp-0008IT-8c for 59976@debbugs.gnu.org; Mon, 12 Dec 2022 10:35:18 -0500 Original-Received: by mail-lj1-f172.google.com with SMTP id a19so197049ljk.0 for <59976@debbugs.gnu.org>; Mon, 12 Dec 2022 07:35:17 -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=x71fJqS/WsL8ufJsnVLdxB8ZVTI7NNwbc9EmhlRLoKs=; b=Rvqo9YV+vq3iC91yM25wjsSLlZM9AmP+kn/I0A5yckhNMdUkmO2X8Jprd+MwrTvXnd VZFl56X9qdntcflhCBU05ZqGK7gxd8iiB7EXda6rU1SWasdpWA0/0e4yOsN54IxEj+9f GZuyHYsct5bYzxeR848vqX79gi3X6Vjqr/gbI8hcvYktqsOELZmL9f/iplkF88VgyL9w NVADHR7ENFwCjRiOOjj80AB0RKPqO+TUw+D/nwtgAmFYjm7HgmPF1rQ30njCE7chXuPk fVOp2/BybsQ0WU5fgpQwqN2AWecsK18DJW/03gA9hxNrpSVCukkhLhmefPiBGF+susxE bhpw== 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=x71fJqS/WsL8ufJsnVLdxB8ZVTI7NNwbc9EmhlRLoKs=; b=wTYSFFRl99o6KLSmqJ2GUb3buWdYfu9vsNTRwYRzviMYx6k/XvZOYRILY7XCdw9Syv lgurpRn5tb0kwzhxXxhy8dBGBrWYC+3zRGz/qD05f+GeKTuV7r1dsZQcWO4gEdvt5jZM R/w6PbKuEgmBvDd1viXW5Cm/hZF8zoSguJpLELNARoQLqsnsAJjJMEHn2nwKPJv40gQL /YrJcZVa50DngMI2+vJLe+i2HbBqlUqK05g6KWYFjjkVzjEWl2eUwz9zNyv8t/QLtA4n o9d2DvtWb0XUNmD96TFmbosZ6rTKC/c/6ehuwkloFJKE7Gum9A5HPFv1SaZxiAh9XupJ qDVQ== X-Gm-Message-State: ANoB5pm+F9tYpP5H0CWG9gG4tLSh4VcVrL8BBghB3JClfEDNeNrPjzD+ oK6yhSof4fggTRqrFhZNHI4= X-Google-Smtp-Source: AA0mqf5q8r07o+Dqo1lMFoa7CcwKhbeRm7q1X0KgfEL90PDk06wodxJXUZkf6ZAhmiFfHc1E46Jn6g== X-Received: by 2002:a05:651c:887:b0:26f:db35:ec42 with SMTP id d7-20020a05651c088700b0026fdb35ec42mr3816372ljq.28.1670859310599; Mon, 12 Dec 2022 07:35:10 -0800 (PST) Original-Received: from malediction ([46.48.96.28]) by smtp.gmail.com with ESMTPSA id i3-20020a2ea363000000b0027775fb1f6csm5981ljn.136.2022.12.12.07.35.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Dec 2022 07:35:09 -0800 (PST) In-Reply-To: <87pmcowuzv.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:250714 Archived-At: On Mon, 12 Dec 2022 06:35:00 -0800 "J.P." wrote: > Mike Kazantsev writes: > > I've needed to use case-sensitive channel names (with matrix2051 ad-hoc > > ircd), wanted to test updated ERC client for that, and stumbled upon > > what looks like a bug there: > > > > When IRC server is named "slack", and then it sends you a message from > > user named "slack", ERC tries to open query-buffer "slack", ends up > > running erc--open-target("slack") which does kill-all-local-variables= () > > when enabling erc-mode in the buffer. > > > > That removes erc-networks--id value there and from then on ERC keeps > > spamming "error in process filter" about erc-networks--id being nil. > > > > > > - What I'm trying to do: > > > > - (erc-tls ...) ;; cleates "slack" server buffer and some channels. > > - Open "slack" buffer =20 >=20 > You mean opened manually, like by issuing a /query slack, right? So this > is in addition to the observation above where "it sends you a message > from user named 'slack'"? Sorry, no, I meant as in (switch-to-buffer "slack"), to type command into. No manual /query command is implied anywhere, but maybe it can also be used to reproduce the issue, given how it should do roughly same thing. > > - Send "/ping myuser" IRC-command there >=20 > You also mention "case-sensitive channel names." It'd be nice to know > what those look like when they first arrive off the wire. (BTW, if > you're expecting ERC to interoperate with a case-sensitive network, like > one for which "#FOO" and "#foo" are distinct channels, then that may > need a separate bug report.) It's not related to this issue at all, and I probably shouldn't have mentioned it, to avoid adding extra confusion, sorry. I.e. "slack" buffer in case of this issue is all-lowercase everywhere. But as a separate unrelated thing, here is specific problem that I was thinking to try solving with updated ERC, as it seem to have some new code added, related to casemapping: (to stress this - it's a separate issue from this one, only here as a curiosity, should be ignored entirely in context of this bug report) Detailed description: https://github.com/progval/matrix2051/issues/41 I thought at first that issue might be CASEMAPPING=3Drfc3454 used there, which I was not familiar with, and assumed that it doesn't behave like ascii/rfc1459 casemapping. So I was thinking to try adding it to new erc-downcase func locally, and fix the issue with case-sensitive channels that way. But after looking at RFC 3454 I've found that it includes casemapping for ASCII letters and pretty much just extends casemapping to larger unicode character set, and should be compatible with ERC, at least for the case of simple ASCII letters. So it seem to be a bug in progval/matrix2051 ad-hoc ircd implementation, which I've reported there at the URL above, with a workaround I've used in ERC mentioned in the first comment there, just in case someone might find it via google when bumping into same issue. So, again, it's not really related to this issue, and not an ERC issue at all, and I probably shouldn't have mentioned it here. > > - Workaround: changing announced name of the server to something else > > helps - "slack" query-buffer gets created and is separate from server= buffer. =20 >=20 > You mean by changing `erc-server-announced-name'? Yes... sort of. As I understand it, this name ends up being converted via erc-networks-alist from erc-server-announced-name to a network symbol (e.g. 'OFTC or 'slack) in erc-network value. So guess my description above is incorrect or somewhat incomplete - what you'd actually want is have symbol in that alist not conflict with query-channel name, not just whatever erc-server-announced-name ends up being. Only slightly related to description above, and should likely be ignored in context of this issue: To set erc-network to 'slack value I ended up replacing that alist lookup with a much simplier local solution: https://github.com/mk-fg/emacs-setup/blob/4dd532b/core/fg_erc.el#L72-L95 (current version uses '=F0=9F=96=A7-slack symbol with that unicode prefix exactly to avoid any name conflicts) It's partly needed because ad-hoc protocol-bridge ircd's don't announce network names, and partly because just seemed simplier to derive them this way, but I didn't think about :id solution that you've mentioned below, which might work even better here. But pretty sure if one did use the alist-to-symbol lookup, they'd=20 end up with same result, e.g. 'slack in erc-network, just like it works with 'OFTC in there. > > Was able to understand what seem to be the issue here by enabling > > logging for erc-networks--id changes to *Messages* like this: > > > > (defun debug-watch-log (sym newval op where) > > (message "Variable update: %s =3D %S -> %S [%S %S]" > > sym (symbol-value sym) newval op where) > > (backtrace)) > > (add-variable-watcher 'erc-networks--id #'debug-watch-log) > > > > (run M-x cancel-debug-on-variable-change afterwards to disable this) =20 >=20 > Thanks for the detective work. In this case, I'm pretty sure the root > cause is not directly related to that variable, despite all appearances. >=20 > BTW, the most helpful insights are usually to be found in the contents > of the *erc-protocol* buffer, which can be generated by calling > `erc-toggle-debug-irc-protocol' before connecting for the first time in > an Emacs session. If you're not comfortable sharing such info on the > tracker, please consider doing so out of band. I think issue should be easily reproducible without needing the protocol logs, by setting erc-network to your own nickname and then sending /msg to yourself, or maybe even e.g. "/q OFTC". Will try it out a bit later and report on whether such trivial ways to do it work. > > I think some kind of disambiguation or conflict-detection for > > query-channel names might be either missing or not working atm, > > but is needed to avoid this happening unintentionally, or maybe > > even on purpose (e.g. to annoy someone by cutting their IRC connection)= . =20 >=20 > Agreed. >=20 > Upon detecting the collision, perhaps the query buffer needs to become > "slack!~slack@example.com" (or "slack@slack/me") and/or the server > buffer "slack/me". Additionally, we could have an option that says to > always use full n!u@h's when naming query buffers instead of adapting > dynamically. >=20 > That said, at the moment, we only support unambiguous "network IDs" via > the ":id" keyword parameter of `erc' and `erc-tls'. IOW, calling these > with args like >=20 > :server "127.0.0.1" > :port 2051 > ... > :id 'Slack >=20 > is supposed to always work. But, I can definitely see how that doesn't > in some cases (e.g., a lowercase `:id'). As you say, you may have no > control over who sends you a query, which is still pertinent in the case > of an explicit `:id' so long as it consists entirely of valid nick > characters. That looks like it might be a good solution to my other issue with deriving names for these ad-hoc protocol-bridge networks mentioned above, thanks for mentioning it. > Unfortunately, the best we can do for ERC 5.5 (Emacs 29) is to mention > somewhere, like in (info "(erc) Network Identifier"), that users really > 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. 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/issues. > > I'm running ERC 5.4.1 from current 0e5d059 git master on Emacs 28.2 > > (replacing "erc" dir in /usr/share/emacs), so it is also possible that > > maybe some change in Emacs 29+ prevents this behavior, but it seems unl= ikely. =20 >=20 > Unlikely, yes. But I sometimes worry about ERC's loaddefs when people > manually shadow/replace instead of building alongside Emacs or > installing from devel: >=20 > (push '("devel" . "https://elpa.gnu.org/devel/") package-archives) I didn't consider that newer ERC can be installed this way, given that it seem to be part of the emacs tree, but good to know, thanks, will probably use this instead. (although tbf it seems more complicated than replacing a dir, but if it's cleaner then yeah, probably best to do it via package-archives) > (Not saying you need to do either, of course.) Thanks again for the very > nice bug report. Thank you for looking into this and work on ERC in general. As someone who spends most of the day looking at emacs, it's by far the most convenient and configurable client for me, that I end up using for pretty much all modern IM protocols because of that. >=20 > J.P. >=20 > P.S. I've attached some patches for Emacs 29 that address issues > discovered while briefly looking into this bug; the first is totally > unrelated and the latter two only tangentially so (in case anyone wants > to take a gander). --=20 Mike Kazantsev // fraggod.net