From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#48598: 28.0.50; buffer-naming collisions involving bouncers in ERC Date: Fri, 22 Apr 2022 11:29:50 +0200 Message-ID: <87k0bh31pt.fsf__45240.3385935881$1650619955$gmane$org@gmx.de> 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> 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="10086"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Damien Cassou , 48598@debbugs.gnu.org, Ted Zlatanov , emacs-erc@gnu.org, Sam Steingold To: "J.P." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 22 11:32:27 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 1nhpeN-0002SH-7a for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Apr 2022 11:32:27 +0200 Original-Received: from localhost ([::1]:46640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nhpeK-0006Dj-F4 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 22 Apr 2022 05:32:24 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nhpd0-000556-7p for bug-gnu-emacs@gnu.org; Fri, 22 Apr 2022 05:31:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57596) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nhpcz-000668-V1 for bug-gnu-emacs@gnu.org; Fri, 22 Apr 2022 05:31:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nhpcz-00016k-T3 for bug-gnu-emacs@gnu.org; Fri, 22 Apr 2022 05:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 22 Apr 2022 09:31:01 +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.16506198094176 (code B ref 48598); Fri, 22 Apr 2022 09:31:01 +0000 Original-Received: (at 48598) by debbugs.gnu.org; 22 Apr 2022 09:30:09 +0000 Original-Received: from localhost ([127.0.0.1]:51493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhpc8-00015I-RC for submit@debbugs.gnu.org; Fri, 22 Apr 2022 05:30:09 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:48715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nhpc2-000139-AI for 48598@debbugs.gnu.org; Fri, 22 Apr 2022 05:30:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650619792; bh=OwCYUEgTBa0iM+Hs63hj84My3aCcgcc+Ss3ZuL5wXGk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=JaqRAps7P/nj/BFE4uBS0zsWw8LHUzOCy9JnBLK3lEml4CQ+qPb1uKKsyAvQjkAPc X70E/c/bIGCIepCGUYJIGwgZVODvfosaxYh8M3lED0ryecII7BGqWwHFbpjkMFtrvu Ebo03suYZX1QzFR5awj/Ot8AtTJdfZ3lv3Mlu2JU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([213.220.148.148]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mr9Bk-1oDGLu0PDi-00oBaj; Fri, 22 Apr 2022 11:29:52 +0200 In-Reply-To: <87v8v2o9l4.fsf@neverwas.me> (J. P.'s message of "Thu, 21 Apr 2022 06:21:59 -0700") X-Provags-ID: V03:K1:DHYEqRqHPjhFKZ26nhLIFYFh3vDMEapYGnSV90MGvk5gTtjpqWP GELPN94rYHqxSroYukwCsaOVVW0VkQ844k5+E2TGbd/Wc5N/LEQs9wBS2hz/VKZccxRdqqH QL9q1Y+yi50jLYPhcGCz7EggHJ9GpAgE3TxMVahHhFLwnvzKydHGt+pSvPYO3vy3/cEsuOI gTWcOlorr3KrEH854Ga8Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:DKaN1OQ/fzc=:0ffcZbfZ0TamkHrw85gACP GQg6iti9+Pl7qE6cOQoO/BQswKur3XjtP6xQ2yNjhsafk2GjAs3YOcVBTjdRGqL74FFfiybN8 3rwDX1LplloMzpym+YxTN1BFSh00Zxw8qNUxF8LBvgbUp6Y/G+ZqpMlSLnp3WdL0QSfrhPdfb x6OZkcp2chy43JXe5zWYmjFZHc/2hYb10QeWOxPKqSBz+No7ulw/9poVLHsWM5SSKhY70zs7X taMW8MYCEapjc7RfQXrNvzKRWYFA96P4Y6w6rUIoxmsQPMPDaFKdGRPEiyGVOLOBWonnX5qwT Vzto0wd7VhSDu+o71GArpdPZ8zfPHVz1LI9m/3azGa9r6weQFp8x3+RGRjGQHrti4dcEYZ2tU Yzec/4sL6fJFHItWdW3+VIZSrj7mRYf/a18dPrQRy/G1uiVU+OgOpQlA0p9vIzdmzpVWhY0gk fWrbKLbG0AObl2siHHzsC+9nwbWS0eGXo2pr6azVdRBom+RUVBW7V3GyQxsPV8PELkqqsm5v7 Cwc0rv9jkZluZBI/pmW9dvDhJ3zNTwznwty4rJZ9r/7lrIwC0zp9Kyb4tJmbhYJ0r5UO0GOgb VZp0+jBx8hCOarF2HQyBhncDAIDd/4Tv3Qm6jUZEctRjt0qkrh5r24I3PCTWcmXn1hvUiVkkv NSSmowlMtJ33DwdAdVoliuO8i4SQpx8Ozfx5GyMVyMDviW2I0PZlhFuKaQD0PCqsKHs/jHJbs UTr3NXWM8erFOLpxV+9qCrLmPKlwizyzw39oYfHAslX4oT01R5cSwFDaPnWAXR0CdGolBnVk 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:230408 Archived-At: "J.P." writes: > Hi Michael, Hi, >> You have said somewhere there is an archive at >> . I cannot access >> this URL. Is there another URL to be used? > > Sorry for the confusion. That's a package.el-only endpoint without any > browsable HTML, i.e., > > (push '("erc-tools" . "https://jpneverwas.gitlab.io/erc-tools/archive/") > package-archives) Indeed, that works, thanks. I've installed erc-5.4.1.48598.0.20220420.474, which seems to be the most recent version. Unfortunately, it isn't obvious what has changed wrt vanilla erc, so I must use ediff-directories. > For future reference, the full patch set is available for browsing here: > > https://git.neverwas.me/repos/erc-tools/tree/bugs/48598/patches/wip > > And is downloadable here: > > https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz Well, this is also good. But for analysis it might be better to read the files with the patches applied. >> Indeed. In Tramp there are two calls of auth-source-search: One call in >> order to retrieve the password, and there I use ':max 1' explicitly (see >> `tramp-read-passwd'). And there is another function used for user/host >> name completion, not looking for the password, and there I use ':max >> most-positive-fixnum' (see `tramp-parse-auth-sources'). But the former >> case could refrain from specifying :max. > > Wow, so my lack of communications skills strikes again! Oh no, please don't underestimate my lack of English! > What I meant to > say was that from my reading of that doc string (basically the de facto > compliance spec), a *back end* ignoring :max is fair game. But I think > the way I wrote it gave the misleading impression I was saying fair game > from the querying client's perspective. But regardless, the tramp > examples are indeed helpful. So, thanks for those. I wouldn't call it fair game. With the Tramp examples you have seen, that a :max property greater than 1 makes sense. >> Making auth-source-pass conform to the auth-source API would always be a >> good thing=E2=84=A2. I don't know whether there exist already such a bug= report, >> otherwise I recommend you to write a new report. > > Agreed. Unless Ted or Damien have anything to add, I'm going to remove > support for pass from this patch series (at least for now, even though > my terrible hacks seem to make it gel well enough). I'll later open a > new bug report asking for clarification on the interface and possibly > include a patch for making auth-source-pass :max aware. Yes, please do so. Hacking around bugs will always result in further trouble mid-term. A bug must be fixed where it happens. Btw, there are further dficiencies. For example, I believe the pass backend does not support the :create and :remove properties (last time I've checked, it were only netrc and secret backends which do). But this is perhaps not the most important problem. > Anyway, here is > the relevant file (in case you're curious), which I believe reflects the > approach you describe: > > https://git.neverwas.me/repos/erc-v3/tree/test/erc-services-tests.el?id= =3D00ad7115#n468 Could you provide the (changed) test files together with the erc package? This makes it more simple to puzzle all changes together, instead of accessing different web locations. > J.P. Best regards, Michael.