GNU bug report logs - #70994
[PATCH] Make cache regeneration work in group names with /

Previous Next

Full log

View this message in rfc822 format

From: James Thomas <jimjoe <at> gmx.net>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 70994 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, Daniel Semyonov <daniel <at> dsemy.com>
Subject: bug#70994: [PATCH] Make cache regeneration work in group names with /
Date: Thu, 08 Aug 2024 06:46:48 +0530

[Message part 1 (text/plain, inline)]

Eric Abrahamsen wrote:

> James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Eric Abrahamsen wrote:
>>
>>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>>
>>>> James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of
>>>> text editors" <bug-gnu-emacs <at> gnu.org> writes:
>>>>
>>>>> Reproduction steps for bug:
>>>>>
>>>>> - emacs -Q
>>>>> - (setq gnus-secondary-select-methods
>>>>>     '((nnatom "github.com/vedang/pdf-tools/commits.atom")))
>>>>>   (setq gnus-select-method '(nnnil ""))
>>>>> - M-x gnus
>>>>> - Open a message in the new group and press *
>>>>> - Add the cache virtual server (info "(gnus) Creating a Virtual Server")
>>>>> - ^ (server buffer) and: g on the cache
>>>>> - RET to open (fails)
>>>>>
>>>>> This is a possible fix that I've tested only on my (limited) setup, for
>>>>> now:
>>>>
>>>> Eric, what do you think of the below patch?
>>>
>>> Thanks for the bump...
>>>
>>> James, wasn't this what bug#69517 was supposed to be fixing?
>>
>> You're right, but that was specifically the 'cache'. In regenerate, all
>> it sees is that the backend is nnml and there's nothing else special
>> about the server.
>
> Okay, thanks.
>
>>> I'm still feeling like we're patching pinhole leaks in a fundamentally
>>> broken system.
>>
>> Sorry if my patch made you think so, but I don't feel that way 🙂. This
>> feature is just tangential and things like slashes in group names are
>> bound to complicate things.
>
> I wasn't complaining about your code :) Just generally grumbling that
> this is so complex.
>
>> But let me see if I can whip up an alternative patch that does things in
>> a simpler way (I did say: 'possible' patch). One thing to decide is
>> whether '%'s are uncommon enough in group names to warrant special
>> treatment in a backend as fundamental as nnml.

I've gone ahead and assumed the above; so now the patch is way simpler.
(Btw I meant to say 'nnmail' above, not 'nnml'). It shouldn't be a
problem: think I remember only Gmail using a % at some point - and a
simple renaming fixes that - perhaps there should be a NEWS entry.

[0001-Bugfix.patch (text/x-patch, attachment)]

[Message part 3 (text/plain, inline)]

Note that for this to work with nnatom in the current upstream you'll
also need (ahem!) my patch in bug#65467: bug#71888 must be responsible.

> Without diving into this right now, it seems like this is something that
> should be governed by the nnmail abstract backend, from which nnml and
> friends inherit. I would dearly, dearly love it if all backends that
> might potentially create an on-disk directory from a group name would
> use the same code (applying the same user options) to do it, essentially
> transparently. It makes me nervous when various functions in various
> places repeat similar-but-not-quite-identical routines in encoding and
> decoding group names. I suppose that URL encoding/decoding functions
> might end up being an okay tool, but I wonder if Elisp doesn't already
> have some prior art here. I'll do a bit of reading.

That's worthwhile of course, but here, for the time being, I've decided
I'm only grappling with the new allowance of '/'s in group names. :-)

(A further improvement involves replacing the '/'s in the code with
'-directory-separator-character', but that's for another report)

Regards,
James

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.