bug#69517: [PATCH] Make gnus cache work with group names having '/'

[Daniel Semyonov via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>>>>> James Thomas writes:

    > Eric Abrahamsen wrote:
    >> The real problem (well, one of the real problems) is that we should just
    >> have two central routines for reading and writing active files, so that
    >> there are only two places to keep in sync. Instead we have those two
    >> places, and then a smattering of other functions in other places that do
    >> something similar, and also have to be kept in sync, and I haven't done
    >> that. At the very least I'll need to apply your patch from 65467.
    >> 
    >> The other real problem is that gnus-cache is confused about whether it
    >> wants to be a select method, or a modified version of article saving.
    >> The presence of `gnus-use-long-file-name' indicates the latter, but the
    >> manual's instructions about the nnml select method indicates the former.
    >> 
    >> I think it should be a select method, which means that the group
    >> directory should be created in "News/cache" the same way it is created
    >> at the top level: with the "/" replaced by "_", and everything else
    >> using the proper "left/right" group name. Perhaps "long file names" can
    >> still play a role, but if so that should be via
    >> `nnmail-use-long-file-names', and gnus-cache in general should behave
    >> like a nnmail backend.

    > Well, I have sort of, an approach based on my earlier patch: [patch]

    > James Thomas wrote:

    >> +	(if (not nnmail-use-long-file-names)
    >> +            (nnheader-replace-chars-in-string group ?. ?/)
    >> +	  group))

    > Since directory names cannot have '/' they used to be replaced by '_' in
    > group names before conversion. But this makes it impossible, when
    > generating (non-existent) active files to know whether a '_' in the
    > directory name was _ or / originally.

    > The above patch tries a possible solution inspired from [1] but would
    > break existing users of the cache or agent (xref-find-references
    > "nnmail-group-pathname") who have groups with % or / in their names.

    > Seems to work in my limited testing. WDYT?

I tested it and it seems to work, but I'm pretty sure it will also break
existing groups with % or / in their names in several backends.
For example, the `nnmh' and `nndiary' backends use this function to
locate groups on disk, which will fail for those groups (unless users
rename the files manually).

FWIW I think this approach is good, but since Gnus doesn't even emit a
warning currently when creating a group with % in its name, I don't
think breaking these groups is a good idea.

Daniel