From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: Deus Max <deusmax@gmx.com>
Cc: 39026@debbugs.gnu.org
Subject: bug#39026: 27.0.50; gnus-group-decoded-name needs running gnus
Date: Mon, 13 Jan 2020 10:51:46 -0800 [thread overview]
Message-ID: <87zhermbp9.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87muaw229i.fsf@aia00054aia.gr> (Deus Max's message of "Thu, 09 Jan 2020 15:22:17 +0200")
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
next prev parent reply other threads:[~2020-01-13 18:51 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-08 2:47 bug#39026: 27.0.50; gnus-group-decoded-name needs running gnus Deus Max
2020-01-08 19:09 ` Eric Abrahamsen
2020-01-09 13:22 ` Deus Max
2020-01-13 18:51 ` Eric Abrahamsen [this message]
2020-01-13 20:57 ` Deus Max
2020-01-14 22:54 ` Eric Abrahamsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zhermbp9.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=39026@debbugs.gnu.org \
--cc=deusmax@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.