[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#39506: patch
From: |
dick . r . chiang |
Subject: |
bug#39506: patch |
Date: |
Sat, 08 Feb 2020 14:01:44 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.60 (gnu/linux) |
> The focus of the sentence is on "before": the previous code already set the
> buffer to unibyte, but it did it afterwards.
Ah, so the buffer in question is merely the working temp-buffer, not the
handle-buffer.
Indeed, the previous code did it afterwards, and therein lies my salvation
because insert-buffer-substring of multibytes to a unibyte buffer corrupts.
I think the Miles Bader code replicated the multibyteness of the
handle-buffer to the temp-buffer, called insert-buffer-substring, and then
converted the temp-buffer to unibyte.
> - How does `mm-with-part` relate to `mm-shr`?
mm-shr calls mm-with-part.
> - Before deciding whether unibyte or multibyte is the right choice, the
> main question is whether the buffer contains bytes or chars.
My buffer contained some Chinese multibytes. You can see my unit test in the
patch.
> AFAIK `mm-with-part` should only ever handle bytes (otherwise calling
> `mm-decode-content-transfer-encoding` doesn't make much sense).
Okay, maybe mm-decode-content-transfer-encoding is a noop when it doesn't make
sense.
I'm not completely on top of all this, but my individual use case rather
prefers the old Miles Bader order of ops. I can easily work around it if you
feel
your 2008 change genuinely fixed something that was broken (my patch is largely
speculative and inconsiderate of broader ramifications).