mm-with-unibyte-current-buffer

mm-with-unibyte-current-buffer

[Katsumi Yamaoka]

I've redefined the `mm-with-unibyte-current-buffer' macro so as
not to bind the default value of `enable-multibyte-characters' to
nil, since it is no longer allowed (causes an error actually) in
Emacs 24.  Formerly it did in a multibyte buffer:

(letf (((default-value 'enable-multibyte-characters) nil))
  (set-buffer-multibyte nil)
  bla bla bla
  (set-buffer-multibyte t))

Now it only does:

  (set-buffer-multibyte nil)
  bla bla bla
  (set-buffer-multibyte t)

The main purpose of having bound it seems to make a unibyte buffer
with `generate-new-buffer', `with-temp-buffer', etc.

Anyway changing the multibyteness of a buffer may cause a serious
trouble to buffer's contents especially if there are multibyte or
8-bit characters.  Though many Gnus modules still use the macro;
I'm not capable to fix them all.  Due to this change some of them
may malfunction.  Please report it together with a recipe; I may
be able to fix it or may not.

,----
| mm-with-unibyte-current-buffer is a Lisp macro in `mm-util.el'.
|
| (mm-with-unibyte-current-buffer &rest FORMS)
|
| Evaluate FORMS with current buffer temporarily made unibyte.
| Equivalent to `progn' in XEmacs.
|
| Note: We recommend not using this macro any more; there should be
| better ways to do a similar thing.  The previous version of this macro
| bound the default value of `enable-multibyte-characters' to nil while
| evaluating FORMS but it is no longer done.  So, some programs assuming
| it if any may malfunction.
`----

Re: mm-with-unibyte-current-buffer

[Eli Zaretskii]

> Date: Mon, 10 May 2010 16:26:29 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: emacs-devel@gnu.org
> 
> I've redefined the `mm-with-unibyte-current-buffer' macro so as
> not to bind the default value of `enable-multibyte-characters' to
> nil, since it is no longer allowed (causes an error actually) in
> Emacs 24.  Formerly it did in a multibyte buffer:
> 
> (letf (((default-value 'enable-multibyte-characters) nil))
>   (set-buffer-multibyte nil)
>   bla bla bla
>   (set-buffer-multibyte t))
> 
> Now it only does:
> 
>   (set-buffer-multibyte nil)
>   bla bla bla
>   (set-buffer-multibyte t)

Binding the value of enable-multibyte-characters may be a no-no, but
_testing_ its value is still possible.  So I see no reason to
set-buffer-multibyte unconditionally, because you may already be in a
unibyte buffer.

> Anyway changing the multibyteness of a buffer may cause a serious
> trouble to buffer's contents especially if there are multibyte or
> 8-bit characters.

Like what?  I thought we are way past this kind of trouble in Emacs 23.

Re: mm-with-unibyte-current-buffer

[Stefan Monnier]

> Binding the value of enable-multibyte-characters may be a no-no, but
> _testing_ its value is still possible.  So I see no reason to
> set-buffer-multibyte unconditionally, because you may already be in a
> unibyte buffer.

But calling set-buffer-multibyte with the current value is harmless (it
checks a returns right away if there's nothing to do; this check might
even be faster than doing it in Elisp).


        Stefan

Re: mm-with-unibyte-current-buffer

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 10 May 2010 13:51:27 -0400
> Cc: Katsumi Yamaoka <yamaoka@jpl.org>, ding@gnus.org, emacs-devel@gnu.org
> 
> > Binding the value of enable-multibyte-characters may be a no-no, but
> > _testing_ its value is still possible.  So I see no reason to
> > set-buffer-multibyte unconditionally, because you may already be in a
> > unibyte buffer.
> 
> But calling set-buffer-multibyte with the current value is harmless (it
> checks a returns right away if there's nothing to do; this check might
> even be faster than doing it in Elisp).

That's true, but the unconditional call `(set-buffer-multibyte t)' at
the end of the macro is _not_ harmless, if the buffer was originally a
unibyte one.

Re: mm-with-unibyte-current-buffer

[Stefan Monnier]

>> > Binding the value of enable-multibyte-characters may be a no-no, but
>> > _testing_ its value is still possible.  So I see no reason to
>> > set-buffer-multibyte unconditionally, because you may already be in a
>> > unibyte buffer.
>> But calling set-buffer-multibyte with the current value is harmless (it
>> checks a returns right away if there's nothing to do; this check might
>> even be faster than doing it in Elisp).
> That's true, but the unconditional call `(set-buffer-multibyte t)' at
> the end of the macro is _not_ harmless, if the buffer was originally a
> unibyte one.

Right, this is "on purpose", IIUC (I don't actually understand what
this macro intends to do, which is why I haven't touched it other than
to add increasingly scary warnings to it).


        Stefan

Re: mm-with-unibyte-current-buffer

[Katsumi Yamaoka]

>>>>> Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Mon, 10 May 2010 13:51:27 -0400
>> Cc: Katsumi Yamaoka <yamaoka@jpl.org>, ding@gnus.org, emacs-devel@gnu.org
>>
>>> Binding the value of enable-multibyte-characters may be a no-no, but
>>> _testing_ its value is still possible.  So I see no reason to
>>> set-buffer-multibyte unconditionally, because you may already be in a
>>> unibyte buffer.
>>
>> But calling set-buffer-multibyte with the current value is harmless (it
>> checks a returns right away if there's nothing to do; this check might
>> even be faster than doing it in Elisp).

> That's true, but the unconditional call `(set-buffer-multibyte t)' at
> the end of the macro is _not_ harmless, if the buffer was originally a
> unibyte one.

The macro runs `(set-buffer-multibyte nil)' first regardless of
the multibyteness of a buffer whatever data are there, and runs
`(set-buffer-multibyte t)' finally.  I don't recall what kind of
data were there, but in the early days of the Emacs 23 development
I saw data were made broken.  Did you mean such a trouble will
never happen with the released Emacs versions?

(Note: Gnus supports Emacs 21~24, XEmacs 21.4&21.5, and SXEmacs.)

Re: mm-with-unibyte-current-buffer

[Katsumi Yamaoka]

>>>>> Katsumi Yamaoka wrote:
>>>>>> Eli Zaretskii wrote:
[...]
>> That's true, but the unconditional call `(set-buffer-multibyte t)' at
>> the end of the macro is _not_ harmless, if the buffer was originally a
>> unibyte one.
[...]
> Did you mean such a trouble will never happen with the released
> Emacs versions?

Oops.  I misread your sentence (that's `not harmless').  Please
disregard my question.

> (Note: Gnus supports Emacs 21~24, XEmacs 21.4&21.5, and SXEmacs.)