all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* mm-with-unibyte-current-buffer
@ 2010-05-10  7:26 Katsumi Yamaoka
  2010-05-10 17:19 ` mm-with-unibyte-current-buffer Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Katsumi Yamaoka @ 2010-05-10  7:26 UTC (permalink / raw)
  To: ding; +Cc: emacs-devel

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.
`----



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mm-with-unibyte-current-buffer
  2010-05-10  7:26 mm-with-unibyte-current-buffer Katsumi Yamaoka
@ 2010-05-10 17:19 ` Eli Zaretskii
  2010-05-10 17:51   ` mm-with-unibyte-current-buffer Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2010-05-10 17:19 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: ding, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mm-with-unibyte-current-buffer
  2010-05-10 17:19 ` mm-with-unibyte-current-buffer Eli Zaretskii
@ 2010-05-10 17:51   ` Stefan Monnier
  2010-05-10 18:47     ` mm-with-unibyte-current-buffer Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2010-05-10 17:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Katsumi Yamaoka, ding, emacs-devel

> 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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mm-with-unibyte-current-buffer
  2010-05-10 17:51   ` mm-with-unibyte-current-buffer Stefan Monnier
@ 2010-05-10 18:47     ` Eli Zaretskii
  2010-05-11  1:02       ` mm-with-unibyte-current-buffer Stefan Monnier
  2010-05-11  1:29       ` mm-with-unibyte-current-buffer Katsumi Yamaoka
  0 siblings, 2 replies; 7+ messages in thread
From: Eli Zaretskii @ 2010-05-10 18:47 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: yamaoka, ding, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mm-with-unibyte-current-buffer
  2010-05-10 18:47     ` mm-with-unibyte-current-buffer Eli Zaretskii
@ 2010-05-11  1:02       ` Stefan Monnier
  2010-05-11  1:29       ` mm-with-unibyte-current-buffer Katsumi Yamaoka
  1 sibling, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2010-05-11  1:02 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: yamaoka, ding, emacs-devel

>> > 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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mm-with-unibyte-current-buffer
  2010-05-10 18:47     ` mm-with-unibyte-current-buffer Eli Zaretskii
  2010-05-11  1:02       ` mm-with-unibyte-current-buffer Stefan Monnier
@ 2010-05-11  1:29       ` Katsumi Yamaoka
  2010-05-11  1:43         ` mm-with-unibyte-current-buffer Katsumi Yamaoka
  1 sibling, 1 reply; 7+ messages in thread
From: Katsumi Yamaoka @ 2010-05-11  1:29 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, ding, emacs-devel

>>>>> 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.)



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mm-with-unibyte-current-buffer
  2010-05-11  1:29       ` mm-with-unibyte-current-buffer Katsumi Yamaoka
@ 2010-05-11  1:43         ` Katsumi Yamaoka
  0 siblings, 0 replies; 7+ messages in thread
From: Katsumi Yamaoka @ 2010-05-11  1:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, ding, emacs-devel

>>>>> 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.)



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2010-05-11  1:43 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-05-10  7:26 mm-with-unibyte-current-buffer Katsumi Yamaoka
2010-05-10 17:19 ` mm-with-unibyte-current-buffer Eli Zaretskii
2010-05-10 17:51   ` mm-with-unibyte-current-buffer Stefan Monnier
2010-05-10 18:47     ` mm-with-unibyte-current-buffer Eli Zaretskii
2010-05-11  1:02       ` mm-with-unibyte-current-buffer Stefan Monnier
2010-05-11  1:29       ` mm-with-unibyte-current-buffer Katsumi Yamaoka
2010-05-11  1:43         ` mm-with-unibyte-current-buffer Katsumi Yamaoka

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.