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: Tue, 30 Apr 2019 10:03:46 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: yamaoka@jpl.org,  35383@debbugs.gnu.org
>> Date: Mon, 29 Apr 2019 13:04:31 -0700
>>
>> >> 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.
>
> Sorry, it was not clear to me, since you talked about "decoding to
> utf-8-emacs", which is a kind of tautology.

True!

>> So you think Gnus' various *-file-coding-system options should
>> default to 'utf-8-emacs rather than 'raw-text?
>
> Not sure about all of them, I don't think I have a clear idea of what
> they are used for.  The principle is that we use utf-8-emacs for files
> where Emacs records its internal data, and whose primary role is to
> allow Emacs to restore its internal data with maximum reliability.
> One good example of this is auto-save files, where we use utf-8-emacs
> regardless of the actual encoding of the file whose buffer is
> auto-saved.
>
> If this principle is not enough to make a decision, please point out
> the specific variables you are unsure about, and I will take a look at
> their actual usage.

I think that's sufficient. I'm really only looking at two variables:
`gnus-agent-file-coding-system', which I'm 100% sure is only used
internally by Gnus/Emacs, and `nnmail-active-file-coding-system', which
I'm 99% sure is only used internally.

>> 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.
>
> That is true, but good defaults do matter to new users and new files.
>
> And raw-text is almost never appropriate as the default for
> human-readable text.
>
>> 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?
>
> What other checks and guarantees did you consider?  (Sorry, I didn't
> read the entire thread, so maybe just point me to the message where
> you described this.)

That's where the encoding cookie idea came from -- if there's no cookie,
read as 'raw-text, otherwise honor the cookie. But as Katsumi Yamaoka
pointed out, the way Gnus reads the file will ignore any encoding
cookie, so that's no good.

To be honest, I didn't have any other ideas.





reply via email to

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