bug#70994: [PATCH] Make cache regeneration work in group names with /

[Eli Zaretskii <eliz@gnu.org>]

Ping!  Can we make some progress here?

> Cc: 70994@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
>  Daniel Semyonov <daniel@dsemy.com>
> Date: Thu, 08 Aug 2024 06:46:48 +0530
> From:  James Thomas via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Eric Abrahamsen wrote:
> 
> > 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.
> 
> 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.
> 
> 
> 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