[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#70994: [PATCH] Make cache regeneration work in group names with /
From: |
Eric Abrahamsen |
Subject: |
bug#70994: [PATCH] Make cache regeneration work in group names with / |
Date: |
Thu, 23 May 2024 18:26:50 -0700 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
> Eric Abrahamsen wrote:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> James Thomas via "Bug reports for GNU Emacs, the Swiss army knife of
>>> text editors" <bug-gnu-emacs@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.
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.
Thank you for persisting with this stuff!
Eric