Gnus development mailing list
 help / color / mirror / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Katsumi Yamaoka <yamaoka@jpl.org>
Cc: bugs@gnus.org, ding@gnus.org, emacs-devel@gnu.org
Subject: Re: Why multibyte for original-article buffer
Date: Thu, 28 Feb 2008 23:22:09 -0500	[thread overview]
Message-ID: <jwv8x145xjy.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <b4mhcfsa9bh.fsf@jpl.org> (Katsumi Yamaoka's message of "Fri, 29 Feb 2008 09:35:30 +0900")

>> I've been running with the following patch with good results.
>> Also the patch makes sense to me: the original article is a sequence of
>> bytes (i.e. encoded chars), so a unibyte buffer makes a lot of sense
>> (it's more efficient and is likely to hide fewer bugs).

> So, it is better to make also the " *nntpd*" buffer, the process
> buffer for pop3, etc. be unibyte.  If such changes cause a problem,
> it will be due to a code that copies data from those buffers to
> a multibyte buffer and then decodes the data.  Actually, making
> the original article buffer be unibyte prevents me from reading
> a Japanese 8bit shift_jis message like this.

> 日本語

> (Try `g' in the summary buffer.)

Indeed, I see that.  The patch below will fix it.

>> Yet the code currently explicitly sets the buffer to multibyte mode.
>> Does anybody know why?

> IIRC, it was done about ten years ago.  I guess it was probably
> a workaround for a problem like the one mentioned above.

Yes, the Gnus code is full of such things.  I suggest it's time to take
a step back and think about how things *should* work.  Then change the
parts for which we know how they should work.  This will introduce bugs,
but then we'll know that the bugs are elsewhere and that fixing them
will get us closer to a good solution.


        Stefan


@@ -6564,7 +6564,13 @@
 		 (with-current-buffer gnus-original-article-buffer
 		   (and (equal (car gnus-original-article) group)
 			(eq (cdr gnus-original-article) article))))
-	    (insert-buffer-substring gnus-original-article-buffer)
+            ;; `insert-buffer-substring' would incorrectly use the
+            ;; equivalent of string-make-multibyte which amounts to decoding
+            ;; with locale-coding-system, causing failure of
+            ;; subsequent decoding.
+            (insert (mm-string-to-multibyte
+                     (with-current-buffer gnus-original-article-buffer
+                       (buffer-substring (point-min) (point-max)))))
 	    'article)
 	   ;; Check the backlog.
 	   ((and gnus-keep-backlog




  reply	other threads:[~2008-02-29  4:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <jwvd4qg3nfg.fsf-monnier+emacs@gnu.org>
2008-02-29  0:35 ` Katsumi Yamaoka
2008-02-29  4:22   ` Stefan Monnier [this message]
2008-02-29  5:44     ` Katsumi Yamaoka
2008-02-29  6:18       ` Miles Bader

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=jwv8x145xjy.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=bugs@gnus.org \
    --cc=ding@gnus.org \
    --cc=emacs-devel@gnu.org \
    --cc=yamaoka@jpl.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).