Re: buff-menu header wrong char

[Stefan Monnier <monnier@iro.umontreal.ca>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1889 bytes --]

> A *Buffer List* looks like this:
> 
>     CRM Buffer                Size  Mode              File
>     ôôô ôôôôôô                ôôôô  ôôôô              ôôôô
>     .   *scratch*                0  Lisp Interaction
>       * *Messages*             150  Fundamental

Hmm... my crystal ball tells me you're running in unibyte mode.
I'd *strongly* advise you don't do that.

>    (if (char-displayable-p ?—) ?— ?-)))

So it seems the problem is that in unibyte mode, char-displayable-p on the
non-ASCII char above returns non-nil (because you do have the font to
display such a char) even though the char will actually not be properly
displayed after it's inserted in the buffer because the insertion into the
unibyte buffer changes the char (I really think it should signal an error
instead, but that's another fight).

Does anyone object to the patch below?


        Stefan


--- mule-util.el	12 oct 2004 12:05:54 -0400	1.56
+++ mule-util.el	03 déc 2004 14:52:41 -0500	
@@ -2,7 +2,7 @@
 
 ;; Copyright (C) 1995 Electrotechnical Laboratory, JAPAN.
 ;; Licensed to the Free Software Foundation.
-;; Copyright (C) 2000, 2002 Free Software Foundation, Inc.
+;; Copyright (C) 2000, 2002, 2004  Free Software Foundation, Inc.
 
 ;; Keywords: mule, multilingual
 
@@ -356,6 +356,9 @@
   (cond ((< char 256)
 	 ;; Single byte characters are always displayable.
 	 t)
+	((not enable-multibyte-characters)
+	 ;; Maybe there's a font for it, but we can't put it in the buffer.
+	 nil)
 	((display-multi-font-p)
 	 ;; On a window system, a character is displayable if we have
 	 ;; a font for that character in the default face of the
@@ -377,5 +380,5 @@
 ;; coding: iso-2022-7bit
 ;; End:
 
-;;; arch-tag: 5bdb52b6-a3a5-4529-b7a0-37d01b0e570b
+;; arch-tag: 5bdb52b6-a3a5-4529-b7a0-37d01b0e570b
 ;;; mule-util.el ends here