bug#39026: 27.0.50; gnus-group-decoded-name needs running gnus

[Eric Abrahamsen]

On 01/09/20 15:22 PM, Deus Max wrote:
> On Wed, Jan 08 2020, Eric Abrahamsen wrote:
>
>> Deus Max <deusmax@gmx.com> writes:
>>
>>> Before starting gnus, running:
>>>    (gnus-group-decoded-name  group-name) ; ex: "nnimap+myserver:GroupName"
>>>
>>> Gives the error:
>>>    ** Eval error ***  Wrong type argument: hash-table-p, nil
>>>
>>> Tracking this down the path:
>>>    - (gnus-group-decoded-name group-name)
>>>      - (gnus-group-name-charset  nil group-name)
>>>        - (gnus-find-method-for-group group-name)
>>>          - (gnus-group-entry group-name)
>>>
>>> The tiny macro gnus-group-entry, simply does a:
>>>     (gethash group-name gnus-newsrc-hashtb)
>>>
>>> The variable gnus-newsrc-hashtb is not a hashtable when gnus is not
>>> running. Logical, it has not been assinged yet.
>>>
>>> To me, it seems unnecessary to require a running gnus for a simple group
>>> name decoding. It is overkill, that loses a lot of offline functinality
>>> and possibilities.
>>
>> In theory, the only way we can know how to decode a group name for sure
>> is by asking its method for the appropriate charset to use, and we can
>> only reasonably do that if Gnus is loaded.
>>
>> In practice, the same changes that put in the hash table also resulted
>> in Gnus group names being always decoded, at least within a running Gnus
>> system, so the call to `gnus-group-decoded-name' is usually unnecessary
>> (the only time the server/method charset comes into play is when we're
>> requesting the group names from the server).
>>
>> Of course if you're trying to do things with groups outside of a running
>> Gnus system, you might be manually reading the group names from
>> the.newsrc.eld file, in which case non-ASCII group names will be in an
>> encoded format, using 'utf-8-emacs.
>>
>> What I'm saying is, depending on how you're using the group names and
>> where you're getting them from, you should be safe simply running them
>> through a 'utf-8-emacs decode.
>>
>> Eric
>
> Yes, that's mostly how I'm using it, i.e. by reading group names from
> .newsrc, but sometimes directly from a gnus group or article. So, it
> would be nice to do some things independent of a running gnus and in a
> consistent way.
>
> I didn't see any charset info returned by querying the server
> (with gnus-find-method-for-group, gnus-group-entry). Logically, the
> method should be provided in the group name, except for the primary
> method (gnus-select-method, perhaps another good reason to get rid of
> this distinction among groups, but I digress, sorry).
>
> It seems that all the real work (in gnus-group-name-charset), for finding
> the charset, comes from the variables gnus-group-name-charset-group-alist
> and gnus-group-name-charset-method-alist which are defined at startup
> and don't need a running gnus.

Yeah, to be honest, I don't really know the point of the
gnus-group-name-charset-* stuff, and am mostly unwilling to mess with
anything I don't really understand. But if those variables have been
set, we'd need to know a group's method, and it really isn't possible to
get a group's method for sure unless Gnus is up and running.

In fact, I suspect we could simply dump all the group-name-charset/group
decoding stuff, stop encoding/decoding altogether, but I don't know how
I would prove that wouldn't cause problems.

Can you just not use gnus-group-decoded-name? As I mentioned, decoding
as 'utf-8-emacs should work fine.

Eric