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#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Fri, 29 Apr 2022 06:03:12 -0700 Message-ID: <87czh02ga7.fsf__12225.087387354$1651237476$gmane$org@neverwas.me> References: <875yzakzvi.fsf@neverwas.me> <87bkxaeyuw.fsf@neverwas.me> <87zgkisetn.fsf@cassou.me> <87ee1ucvv3.fsf@neverwas.me> <87tuaqs9br.fsf__15054.4815858424$1650295523$gmane$org@cassou.me> <87k0bmbage.fsf@gmx.de> <878rrz268v.fsf@neverwas.me> <87czha3oc5.fsf_-_@gmx.de> <87v8v2o9l4.fsf@neverwas.me> <87k0bh31pt.fsf@gmx.de> <8735i5nql8.fsf@neverwas.me> <87bkws2ksn.fsf@gmx.de> <87czh5z7ui.fsf@neverwas.me> <874k2epv5n.fsf@gmx.de> 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="17559"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 48598@debbugs.gnu.org, emacs-erc@gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 29 15:04:28 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 1nkQIO-0004I7-5x for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Apr 2022 15:04:28 +0200 Original-Received: from localhost ([::1]:57280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nkQIM-0006BL-Tq for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 29 Apr 2022 09:04:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40180) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkQI0-0006A6-Ab for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 09:04:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57307) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nkQHy-0000EA-8m for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 09:04:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nkQHy-0000fp-2a for bug-gnu-emacs@gnu.org; Fri, 29 Apr 2022 09:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 29 Apr 2022 13:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48598 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 48598-submit@debbugs.gnu.org id=B48598.16512374042545 (code B ref 48598); Fri, 29 Apr 2022 13:04:02 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 29 Apr 2022 13:03:24 +0000 Original-Received: from localhost ([127.0.0.1]:51204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQHM-0000ez-19 for submit@debbugs.gnu.org; Fri, 29 Apr 2022 09:03:24 -0400 Original-Received: from mail-108-mta10.mxroute.com ([136.175.108.10]:45125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkQHL-0000en-0U for 48598@debbugs.gnu.org; Fri, 29 Apr 2022 09:03:23 -0400 Original-Received: from filter006.mxroute.com ([140.82.40.27] 140.82.40.27.vultrusercontent.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta10.mxroute.com (ZoneMTA) with ESMTPSA id 180756b1c39000fe85.001 for <48598@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 29 Apr 2022 13:03:15 +0000 X-Zone-Loop: 932dd2059d7c425fa4dc1d0b405a82a728c5586e09e2 X-Originating-IP: [140.82.40.27] 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: In-Reply-To:Date:References: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=qUWLhQ2VGwiaAILyBoMvyr3Kzc4pRE86A8cgjkVDloI=; b=AODyAIL3q0FXPdArrqxXAAtuIN VMCSbdu449O4FYb14V6y6KLoDZTTs5evVWtj3pycNQBXlAFfLri6M3Bi1+FjdJPmWk+WuiVOcOUvR gni+t3N4SmoZsGApnBvWJWFaWf/J4+SJDIDXXilW/0yc/88zyjpGMLn9UZDvNhGCCqh7CNwtTsPyr xnrqwIjoMXdsCY560HdqUugxEtjHhr0ChOaEwQ96L+/4mDHjz0W0bj2WwOzoESUeN1uf/iBpXA6V2 od+drBuu/TQlVu0YTWJLjpisfWCTvPFPqH3PrNLkDshnPsDFcNpM9+bmUawQAxoKnlsf4LPLTJcYV eRPo7zHg==; In-Reply-To: <874k2epv5n.fsf@gmx.de> (Michael Albinus's message of "Wed, 27 Apr 2022 14:28:52 +0200") X-AuthUser: 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" Xref: news.gmane.io gmane.emacs.bugs:230955 Archived-At: Hi Michael, Michael Albinus writes: > I'm now at erc 5.4.1.48598.0.20220425.270. Btw, it is a little bit > tricky to decide which is the recent version, because you have two > lines of patches: erc5.4.1.48598.* and erc 5.4.1.49860.*. The package > manager always offers me to upgrade to the most recent 5.4.1.49860.* > version, and I must pick then the most recent 5.4.1.48598.* version > (hoping it is the proper decision). It might be more obvious to me if > you could offer both erc-48598 and erc-49860 packages in parallel. Thanks for the feedback on this. I've done as you suggest and am now offering both in parallel. As a strange bonus, this has also helped make the web UI usable: https://jpneverwas.gitlab.io/erc-tools/archive/ Not that you should care, but when the time comes to redo this setup for actual use, I'll have to try and reassess whether the behavior we want is really supported and sustainable. (Hopefully, the ELPA and/or package.el people will be willing to advise.) At the moment, this approach of using separate packages feels quite shaky, for example, with how the shadowing of the built-in ERC happens or how a "main file" matching the package name (such as erc-5xxxx.el) is expected at various points. Such wrinkles will have to be ironed out because we'll be adding packages for bugs in a mostly automated fashion, with the eventual goal being to allow ordinary folks (some of whom may be new to Emacs) to try these fixes and report back findings. It kills me that many people offer to be guinea pigs, but as soon as you mention applying patches: poof! They're gone. > Indeed, test/Makefile fires an error then. I've pushed a fix to master, > it shall work now with the file name erc-d-tests.el. > > [From your most recent email] > > I've poked around this problem. Looks like there is a better solution. > If your test directory is not called test/lisp/erc/, but > test/lisp/erc-tests/, you can locate there test packages with an > arbitrary name, like erc-tests.el or erc-d-tests.el, which don't > require a corresponding library under lisp/erc/. This is described in > test/[file-organization.org], and it will work also with older > Emacsen. > I revert the aforementioned patch in test/Makefile therefore. Thanks a lot for investigating. I was under the mistaken impression that the -tests/ suffix was reserved for deeper libraries, like those under lisp/emacs-lisp/. So, with this in mind, I guess it all comes down to whether we want to a. keep the erc-scenarios/ subdir or change to a flat layout b. rename all scenarios using -tests.el, thus requiring a move to test/lisp/erc-tests/ For (a), staying with the status quo means that tests in erc-resources are excluded from test-lisp-erc-inotify, though this seems irrelevant because all scenarios-based tests are expensive anyway. At present, the only inexpensive tests in that subdir reside in erc-d-self.el. But having those wait around at most eight hours to run seems fine because their natural place is alongside those expensive scenarios, I think. As for actual potential downsides of keeping the subdir, one might be that it makes ERC the odd man out. AFAICT, no other subdirs with ad hoc names exist under test/lisp, and there's no mention in file-organization.org (AFICT) of such names being supported. For (b), keeping the status quo would mean existing references and hyperlinks are preserved (a plus, IMO). Since, all tests are still discovered without undergoing a move, I'm not sure if there's a clear benefit to the latter other than (again) compliance with established norms. Specifically, if people might be annoyed at having tests under a plain test/lisp/erc/ live in files not suffixed by -tests.el, we should probably appease them. In the end, any combination is fine by me, really. >> For now, I've moved it to test/lisp/erc/erc-scenarios/resources/erc-d/ >> and am artificially piggybacking on check-lisp-erc-erc-scenarios via >> test/lisp/erc/erc-scenarios/erc-scenarios-meta.el, which does nothing >> but load erc-d-self.el (as convoluted as that sounds). > > Where is this needed? I don't see any load of erc-scenarios-meta.el. > > And even if you need it somewhere, I believe it belongs into the > resources/ subdirectory. Right. The point was to ensure those tests in erc-d-self.el would be discovered for the check-lisp-erc-erc-scenarios target and also during the test-all-inotify job (check-expensive). But replacing that "meta" file with the real thing (erc-d-self.el itself) works just as well and avoids the indirection. If this is still problematic, I'm fine with simply hiding erc-d-self.el under resources/ and never running it on EMBA or just deleting it (along with all its resources). >> test/lisp/erc/ >> =E2=94=9C=E2=94=80=E2=94=80 erc-tests.el >> ... >> =E2=94=94=E2=94=80=E2=94=80 erc-scenarios/ >> =E2=94=9C=E2=94=80=E2=94=80 erc-scenarios-.el >> =E2=94=9C=E2=94=80=E2=94=80 erc-d.self.el <- fo= rmerly "meta" >> ... >> =E2=94=94=E2=94=80=E2=94=80 resources/ >> =E2=94=9C=E2=94=80=E2=94=80 /... >> ... >> =E2=94=9C=E2=94=80=E2=94=80 erc-d/ >> =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 erc-d.el >> =E2=94=82=C2=A0=C2=A0 ... >> =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 (erc-d-self.= el) <- gone >> =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 resources/..= . <- renamed >> =E2=94=94=E2=94=80=E2=94=80 erc-scenarios-common.el > > Looks OK to me except the location of erc-scenarios-meta.el. For the sake of contrast, here's what the above would look like without the subdir and with -tests.el everywhere (although these can be applied independently): test/lisp/erc-tests/ =E2=94=9C=E2=94=80=E2=94=80 erc-tests.el ... =E2=94=9C=E2=94=80=E2=94=80 erc-d-tests.el =E2=94=9C=E2=94=80=E2=94=80 erc-scenarios--tests.el ... =E2=94=94=E2=94=80=E2=94=80 resources/ =E2=94=9C=E2=94=80=E2=94=80 /... ... =E2=94=9C=E2=94=80=E2=94=80 erc-d/ =E2=94=82=C2=A0=C2=A0 =E2=94=9C=E2=94=80=E2=94=80 erc-d.el =E2=94=82=C2=A0=C2=A0 ... =E2=94=82=C2=A0=C2=A0 =E2=94=94=E2=94=80=E2=94=80 resources/... =E2=94=94=E2=94=80=E2=94=80 erc-scenarios-common.el > Well, there seems to be a cut'n'waste error in erc-services-tests.el. See > this fix: [...] > > ! (erc-services-tests--auth-source-standard > #'erc--auth-source-search)))) Sadly typical on my part. Thanks. Is there any preference as to whether these should stick around even though they're unused? (I had originally planned on removing them.) >> Sorry again for the packaging snafu. Despite all appearances, I really >> do value your time, so please don't let this interfere (too much) with >> whatever else is on your plate. You've already helped me so much, and I >> owe you a ton! > > No need to sorry! That's what reviews are good for :-) Definitely! (Always appreciated.)