bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#35383: 27.0.50; Complete process of decoding Gnus group names


From: Eric Abrahamsen
Subject: bug#35383: 27.0.50; Complete process of decoding Gnus group names
Date: Mon, 29 Apr 2019 13:04:31 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On 04/29/19 18:41 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <address@hidden>
>> Date: Sun, 28 Apr 2019 21:07:23 -0700
>> Cc: address@hidden
>> 
>> > The goal is to have Gnus default to writing its active files in
>> > 'utf-8-emacs, unless the user has specifically requested otherwise.
>> > `nnmail-active-file-coding-system' governs the "mail" type servers, and
>> > `gnus-agent-file-coding-system' governs the agent. Currently those two
>> > options default to 'raw-text, we'd like them to default to 'utf-8-emacs.
>> 
>> Actually, maybe that's wrong. We don't care how the files are written,
>> only that, after parsing, the group names are successfully _decoded_ to
>> 'utf-8-emacs. Maybe I'm trying too hard?
>
> When you decode _any_ text by _any_ coding-system, the result is
> _always_ utf-8-emacs, because utf-8-emacs is the internal
> representation of characters and raw bytes in Emacs buffers and
> strings.

I did know that much! I'm pretty bad at encoding, but not quite that
bad.

> We write text out as utf-8-emacs when we don't want to risk the danger
> of decoding incorrectly due to local customizations and language
> environments.  Text encoded in utf-8-emacs can by definition represent
> _any_ character and raw byte that Emacs can read, and the "decoding"
> in this case is trivial.
>
> So no, you are not trying too hard, not IMO.

So you think Gnus' various *-file-coding-system options should
default to 'utf-8-emacs rather than 'raw-text?

As per your other message, it sounds like active files written as
'raw-text will probably survive being read as 'utf-8-emacs. And if the
user has previously customized those options to something else, the
change in default value won't matter anyway.

What I meant by "trying too hard" is, maybe it's enough to just change
the defaults, and not add any other error checking and guarantees?

Thanks for looking at this,
Eric





reply via email to

[Prev in Thread] Current Thread [Next in Thread]