23.0.60; describe-char gives wrong information

23.0.60; describe-char gives wrong information

[Peter Dyballa]

Hello!

When inquiring information for Ὀ (i.e. a capital Omicron and a  
psili), maybe not correctly "composed" coming from a XeTeX document,  
GNU Emacs 23.0.60 tells me:

	        character: Ο (927, #o1637, #x39f)
	preferred charset: gb18030 (GB18030)
	       code point: 0xA6AF
	           syntax: w 	which means: word
	         category: G:Greek characters of 2-byte character sets  
c:Chinese g:Greek h:Korean
			   j:Japanese
	      buffer code: #xCE #x9F
	        file code: #xCE #x9F (encoded by coding system utf-8-unix)
	          display: composed to form "Ὀ" (see below)
	
	Composed with the following character(s) "̓" by the rule:
		(?Ο (tc . bc) ?̓)
	The component character(s) are displayed by these fonts (glyph codes):
	 Ο: -Misc-Fixed-Medium-R-Normal--13-120-75-75-C-80-ISO8859-7 (#xCF)
	 ̓: -monotype-arial unicode ms-medium-r-normal--13-127-74-74-p-129- 
gb18030.2000-0 (#xBE35)
	See the variable `reference-point-alist' for the meaning of the rule.
	
	Character code properties are not shown: customize what to show
	
	There are text properties here:
	  auto-composed        t
	  composition          [Show]
	  fontified            t

Character U+039F can't hardly belong to a Chinese encoding. It's a  
Greek character, taken off an ISO 8859-7 font. Its psili modifier or  
COMBINING COMMA ABOVE is at U+0313, outside any Chinese encoding, too  
(although GB18030-2000 defines both as 0xA6AF and as 0x8130BE35).  
Isn't Unicode, as in the name "Unicode Emacs," more appropriate? The  
"code point" data shown above is obviously the GB18030 representation  
of GREEK CAPITAL LETTER OMICRON. The buffer and file code of #xCE  
#x9F stands for GREEK CAPITAL LETTER OMICRON at U+039F in UTF-8.

And then there is no sense in using a non-existing character from an  
inappropriate font when the default font, Lucida Sans Typewriter, has  
this character COMBINING COMMA ABOVE. And this font also has GREEK  
CAPITAL LETTER OMICRON at U+039F.


Similarly GNU Emacs 23.0.60 handles Ὀ (i.e. one letter Omicron with  
psili):

	        character: Ὀ (8008, #o17510, #x1f48)
	preferred charset: gb18030 (GB18030)
	       code point: 0x81369132
	           syntax: w 	which means: word
	         category: g:Greek
	      buffer code: #xE1 #xBD #x88
	        file code: #xE1 #xBD #x88 (encoded by coding system utf-8-unix)
	          display: by this font (glyph code)
	     -monotype-arial unicode ms-medium-r-normal--10-98-74-74-p-99- 
gb18030.2000-0 (#x9132)
	
	Character code properties: customize what to show
	  name: GREEK CAPITAL LETTER OMICRON WITH PSILI
	  general-category: Lu (Letter, Uppercase)
	  decomposition: (927 787) ('Ο' '̓')
	
	There are text properties here:
	  auto-composed        t
	  fontified            t

And although it claims taking GREEK CAPITAL LETTER OMICRON WITH PSILI  
at U+1F48 off Arial Unicode MS, which has this glyph, it uses an open  
box to display it. Because U+1F48 is not defined in GB18030? The byte  
sequence (code point) 0x81369132 is not defined in GB18030-2000.


In GNU Emacs 23.0.60.1 (powerpc-apple-darwin8.11.0, X toolkit, Xaw3d  
scroll bars)
  of 2007-12-30 on Latsche.local
Windowing system distributor `The XFree86 Project, Inc', version  
11.0.40400000
configured using `configure  '--with-x-toolkit=lucid' '--without-gtk'  
'--with-dbus' '--without-sound' '--without-pop' '--with-xpm' '--with- 
jpeg' '--with-tiff' '--with-gif' '--with-png' '--enable- 
locallisppath=/Library/Application Support/Emacs/calendar22:/Library/ 
Application Support/Emacs/caml:/Library/Application Support/Emacs:/sw/ 
share/emacs21/site-lisp/elib' 'PKG_CONFIG_PATH=/sw/lib/freetype219/ 
lib/pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/pkgconfig:/sw/ 
lib/system-openssl/lib/pkgconfig:/sw/share/pkgconfig:/usr/lib/ 
pkgconfig:/usr/local/lib/pkgconfig:/usr/local/clamXav/lib/pkgconfig:/ 
usr/local/lib/pkgconfig' 'CPPFLAGS=-no-cpp-precomp -D__BIND_NOSTATIC - 
I/usr/include/openssl -I/sw/include/pango-1.0 -I/sw/lib/fontconfig2/ 
include -I/sw/lib/freetype219/include -I/sw/lib/freetype219/include/ 
freetype2 -I/sw/include -I/usr/local/include -idirafter /usr/X11R6/ 
include' 'CXXFLAGS=-no-cpp-precomp -I/usr/include/openssl -I/sw/ 
include/pango-1.0 -I/sw/lib/fontconfig2/include -I/sw/lib/freetype219/ 
include -I/sw/lib/freetype219/include/freetype2 -I/sw/include -I/usr/ 
local/include' 'CFLAGS=-bind_at_load -pipe -fPIC -mcpu=7450 - 
mtune=7450 -fast -mpim-altivec -ftree-vectorize -foptimize-register- 
move -freorder-blocks -freorder-blocks-and-partition -fthread-jumps - 
fpeephole -fno-crossjumping' 'LDFLAGS=-dead_strip -multiply_defined  
suppress -L/sw/lib/ncurses -L/sw/lib/fontconfig2/lib -L/sw/lib/ 
freetype219/lib -L/sw/lib -L/usr/local/lib -L/usr/X11R6/lib''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
   TeX-PDF-mode: t
   shell-dirtrack-mode: t
   show-paren-mode: t
   display-time-mode: t
   desktop-save-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   global-auto-composition-mode: t
   auto-composition-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

--
Greetings

   Pete

A common mistake that people make when trying to design something  
completely foolproof is to underestimate the ingenuity of complete  
fools.

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

Sorry for the late response.

In article <C2305CE0-0122-48D7-8B3A-96C3D223F6E5@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Hello!
> When inquiring information for Ὀ (i.e. a capital Omicron and a  
> psili), maybe not correctly "composed" coming from a XeTeX document,  
> GNU Emacs 23.0.60 tells me:

> 	        character: Ο  (927, #o1637, #x39f)
> 	preferred charset: gb18030 (GB18030)
> 	       code point: 0xA6AF
> 	           syntax: w 	which means: word
> 	         category: G:Greek characters of 2-byte character sets  
> c:Chinese g:Greek h:Korean
> 			   j:Japanese
> 	      buffer code: #xCE #x9F
> 	        file code: #xCE #x9F (encoded by coding system utf-8-unix)
> 	          display: composed to form "Ὀ" (see below)
	
> 	Composed with the following character(s) "̓ " by the rule:
> 		(?Ο  (tc . bc) ?̓ )
> 	The component character(s) are displayed by these fonts (glyph codes):
> 	 Ο : -Misc-Fixed-Medium-R-Normal--13-120-75-75-C-80-ISO8859-7 (#xCF)
> 	 ̓ : -monotype-arial unicode ms-medium-r-normal--13-127-74-74-p-129- 
> gb18030.2000-0 (#xBE35)
> 	See the variable `reference-point-alist' for the meaning of the rule.
	
> 	Character code properties are not shown: customize what to show
	
> 	There are text properties here:
> 	  auto-composed        t
> 	  composition          [Show]
> 	  fontified            t

> Character U+039F can't hardly belong to a Chinese encoding. It's a  
> Greek character, taken off an ISO 8859-7 font.

Actuallyy many CJK charsets contain Greek letters.  As you
are in de_DE locale, the order of iso-8859-7 and gb18030 in
charset list is arbitrary.  Try C-x C-m l greek RET C-u C-x
=.  iso-8859-7 should be preferred.

> Its psili modifier or  
> COMBINING COMMA ABOVE is at U+0313, outside any Chinese encoding, too  
> (although GB18030-2000 defines both as 0xA6AF and as 0x8130BE35).  
> Isn't Unicode, as in the name "Unicode Emacs," more
> appropriate?

For the moment, I don't have a good idea about how to order
character sets that are outside of users locale.  Perhaps,
if the character doesn't belong to any of:
 (get-language-info current-language-environment 'charset)
the "preferred charset" line should not be showned.

> And then there is no sense in using a non-existing character from an  
> inappropriate font when the default font, Lucida Sans Typewriter, has  
> this character COMBINING COMMA ABOVE. And this font also has GREEK  
> CAPITAL LETTER OMICRON at U+039F.

Oops, Emacs assumed that GB18030 fonts contains all GB18030
characters.  I've just installed a fix to check the contents
of GB18030 fonts before using it.

By the way, in emacs-unicode-2, the default fontset is not
yet tuned well for Unicode.  For instance, for Latin,
currently only these fonts are registered:

"ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-9"
"ISO8859-10" "ISO8859-13" "ISO8859-14" "ISO8859-15"
"VISCII1.1-1"

As none of them have U+0313, Emacs tries these fallback fonts:

"gb2312.1980" "gbk-0" "gb18030" "jisx0208" "ksc5601.1987"
"CNS11643.1992-1" "CNS11643.1992-2" "CNS11643.1992-3"
"CNS11643.1992-4" "CNS11643.1992-5" "CNS11643.1992-6"
"CNS11643.1992-7" "big5" "jisx0213.2000-1" "jisx0213.2004-1"
"jisx0212" "ISO10646-1"

I agree that this doesn't yield a good result, but the
strategy of "use the default font if it contains the
charater" is also not good for non-Latin users.  Perhaps, to
use the default font or not should depend on the language
environment.

> Similarly GNU Emacs 23.0.60 handles Ὀ  (i.e. one letter Omicron with  
> psili):

> 	        character: Ὀ  (8008, #o17510, #x1f48)
> 	preferred charset: gb18030 (GB18030)
> 	       code point: 0x81369132
> 	           syntax: w 	which means: word
> 	         category: g:Greek
> 	      buffer code: #xE1 #xBD #x88
> 	        file code: #xE1 #xBD #x88 (encoded by coding system utf-8-unix)
> 	          display: by this font (glyph code)
> 	     -monotype-arial unicode ms-medium-r-normal--10-98-74-74-p-99- 
> gb18030.2000-0 (#x9132)
[...]
> And although it claims taking GREEK CAPITAL LETTER OMICRON WITH PSILI  
> at U+1F48 off Arial Unicode MS, which has this glyph, it uses an open  
> box to display it. Because U+1F48 is not defined in GB18030? The byte  
> sequence (code point) 0x81369132 is not defined in GB18030-2000.

If that font doesn't contain that character, with the above
change, that font won't be used.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 08.01.2008 um 06:55 schrieb Kenichi Handa:

>> Character U+039F can't hardly belong to a Chinese encoding. It's a
>> Greek character, taken off an ISO 8859-7 font.
>
> Actuallyy many CJK charsets contain Greek letters.  As you
> are in de_DE locale, the order of iso-8859-7 and gb18030 in
> charset list is arbitrary.  Try C-x C-m l greek RET C-u C-x
> =.  iso-8859-7 should be preferred.

Hello!

I actually intended to emphasise that I was living and working in an  
UTF-8 area. And of course I thought it's absurd ordering a Greek  
letter into a Chinese encoding. To me it seems to belong more to  
German(y), since one of their last kings came from Bavaria.

In my understanding de_DE.UTF-8 says I'm coming from a German  
location in an UTF-8 world, outside any proprietary CJK encodings.

>
>> Its psili modifier or
>> COMBINING COMMA ABOVE is at U+0313, outside any Chinese encoding, too
>> (although GB18030-2000 defines both as 0xA6AF and as 0x8130BE35).
>> Isn't Unicode, as in the name "Unicode Emacs," more
>> appropriate?
>
> For the moment, I don't have a good idea about how to order
> character sets that are outside of users locale.  Perhaps,
> if the character doesn't belong to any of:
>  (get-language-info current-language-environment 'charset)
> the "preferred charset" line should not be showned.

This returns in my UTF-8 *scratch* buffer an absurd

	(iso-8859-1)

I never set a language-environment because I had found with others  
that this is bringing me back into the world of 7 bit encodings  
(maybe also 8 bit).

>
> By the way, in emacs-unicode-2, the default fontset is not
> yet tuned well for Unicode.  For instance, for Latin,
> currently only these fonts are registered:
>
> "ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-9"
> "ISO8859-10" "ISO8859-13" "ISO8859-14" "ISO8859-15"
> "VISCII1.1-1"

Why is ISO 8859-16 missing?

>
>
>> Similarly GNU Emacs 23.0.60 handles Ὀ  (i.e. one letter Omicron  
>> with
>> psili):
>
>> 	        character: Ὀ  (8008, #o17510, #x1f48)
>> 	preferred charset: gb18030 (GB18030)
>> 	       code point: 0x81369132
>> 	           syntax: w 	which means: word
>> 	         category: g:Greek
>> 	      buffer code: #xE1 #xBD #x88
>> 	        file code: #xE1 #xBD #x88 (encoded by coding system utf-8- 
>> unix)
>> 	          display: by this font (glyph code)
>> 	     -monotype-arial unicode ms-medium-r-normal--10-98-74-74-p-99-
>> gb18030.2000-0 (#x9132)
> [...]
>> And although it claims taking GREEK CAPITAL LETTER OMICRON WITH PSILI
>> at U+1F48 off Arial Unicode MS, which has this glyph, it uses an open
>> box to display it. Because U+1F48 is not defined in GB18030? The byte
>> sequence (code point) 0x81369132 is not defined in GB18030-2000.
>
> If that font doesn't contain that character, with the above
> change, that font won't be used.

Arial Unicode has U+1F48. It does not have it in a gb18030.2000-0  
font encoding, because this code point is not defined in  
GB18030-2000. So one of the first mistakes is to assume U+1F48 is  
defined in GB18030-2000 and another one is to use a partial font  
encoding like gb18030.2000-0 instead of a more complete and in an  
UTF-8 environment more appropriate iso10646-1 font encoding.

--
Greetings

   Pete

Math illiteracy affects 7 out of every 5 Americans.

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <3167E3EC-A084-4229-9531-AC3E5BDF69BB@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> > For the moment, I don't have a good idea about how to order
> > character sets that are outside of users locale.  Perhaps,
> > if the character doesn't belong to any of:
> >  (get-language-info current-language-environment 'charset)
> > the "preferred charset" line should not be showned.

> This returns in my UTF-8 *scratch* buffer an absurd

> 	(iso-8859-1)

Ah, providing a good default setting for various locale
(especially for UTF-8 based ones) has been in my todo-list
long.  I once proposed a method of generating a proper
language environment from locale, but it was rejected.

> I never set a language-environment because I had found with others  
> that this is bringing me back into the world of 7 bit encodings  
> (maybe also 8 bit).

> >
> > By the way, in emacs-unicode-2, the default fontset is not
> > yet tuned well for Unicode.  For instance, for Latin,
> > currently only these fonts are registered:
> >
> > "ISO8859-1" "ISO8859-2" "ISO8859-3" "ISO8859-4" "ISO8859-9"
> > "ISO8859-10" "ISO8859-13" "ISO8859-14" "ISO8859-15"
> > "VISCII1.1-1"

> Why is ISO 8859-16 missing?

Just forgotten to be added.  I've just installed a fix.

> Arial Unicode has U+1F48. It does not have it in a gb18030.2000-0  
> font encoding, because this code point is not defined in  
> GB18030-2000. So one of the first mistakes is to assume U+1F48 is  
> defined in GB18030-2000

The charset GB18030-2000 surely contains U+1F48.  Actually
it contains all Unicode characters.

> and another one is to use a partial font  
> encoding like gb18030.2000-0

What do you mean by "partial font encoding"?  Anyway, as I
wrote before, the bug of selecting a font that doesn't have
the character should be fixed now.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]


Am 09.01.2008 um 03:51 schrieb Kenichi Handa:

>> Arial Unicode has U+1F48. It does not have it in a gb18030.2000-0
>> font encoding, because this code point is not defined in
>> GB18030-2000. So one of the first mistakes is to assume U+1F48 is
>> defined in GB18030-2000
>
> The charset GB18030-2000 surely contains U+1F48.  Actually
> it contains all Unicode characters.
>
>> and another one is to use a partial font
>> encoding like gb18030.2000-0
>
> What do you mean by "partial font encoding"?  Anyway, as I
> wrote before, the bug of selecting a font that doesn't have
> the character should be fixed now.

Can be I misunderstood the standard and saw gaps in it when there  
none. Anyway: fact is that a few programmes show that arial unicode  
ms has U+1F48 and GNU Emacs 23.0.60 does not display it from the  
font's gb18030.2000-0 encoding. I am attaching two screenshots from  
xfd. The gb18030.2000-0 encoding variant starts far behind Greek at U 
+8140, which I understand as: this encoding does not provide glyphs  
outside some Chinese block(s).


[-- Attachment #2: pastedGraphic.tiff --]
[-- Type: image/tiff, Size: 964714 bytes --]

[-- Attachment #3: Type: text/plain, Size: 3 bytes --]





[-- Attachment #4: pastedGraphic.tiff --]
[-- Type: image/tiff, Size: 1087152 bytes --]

[-- Attachment #5: Type: text/plain, Size: 159 bytes --]


--
Greetings

   Pete

November, n.:
         The eleventh twelfth of a weariness.
                 – Ambrose Bierce, "The Devil's Dictionary"




[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: 23.0.60; describe-char gives wrong information

[Miles Bader]

BTW it's probably not a good idea to post 3 MB messages to this mailing
list.  [The TIFF files you attached seem to be completely uncompressed;
converting them to PNG format reduces the size by a factor of 20!]

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 09.01.2008 um 12:19 schrieb Miles Bader:

> BTW it's probably not a good idea to post 3 MB messages to this  
> mailing
> list.  [The TIFF files you attached seem to be completely  
> uncompressed;
> converting them to PNG format reduces the size by a factor of 20!]

Sorry! I assumed Snapz was put into PNG mode ... well, it actually  
is! So the change must have happened via copy&paste! From 80 KB to 1  
MB each. I'll change my mode of operation in case there are no  
preferences I can set to prevent this happening!

--
Greetings

   Pete

If my theory of relativity is proven successful, Germany will claim  
me as a German, and France will declare that I am a citizen of the  
world. Should my theory prove untrue, France will say that I am a  
German, and Germany will declare that I am a Jew.
				– Albert Einstein, 1929

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <60200667-2BCD-4D24-BC0F-700361E632A2@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

>>> Arial Unicode has U+1F48. It does not have it in a gb18030.2000-0
>>> font encoding, because this code point is not defined in
>>> GB18030-2000. So one of the first mistakes is to assume U+1F48 is
>>> defined in GB18030-2000
> >
> > The charset GB18030-2000 surely contains U+1F48.  Actually
> > it contains all Unicode characters.
> >
>>> and another one is to use a partial font
>>> encoding like gb18030.2000-0
> >
> > What do you mean by "partial font encoding"?  Anyway, as I
> > wrote before, the bug of selecting a font that doesn't have
> > the character should be fixed now.

> Can be I misunderstood the standard and saw gaps in it when there  
> none.

A font labelled as GB18030.2000 doesn't necessarily contains
all characters of the charset GB18030.2000.

> Anyway: fact is that a few programmes show that arial unicode  
> ms has U+1F48 and GNU Emacs 23.0.60 does not display it from the  
> font's gb18030.2000-0 encoding. I am attaching two screenshots from  
> xfd. The gb18030.2000-0 encoding variant starts far behind Greek at U 
> +8140, which I understand as: this encoding does not provide glyphs  
> outside some Chinese block(s).

You are still confusing with the encoding and the repertory.
"GB18030.2000-0" is a part of a XLFD fontname showing the
encoding of the font, and it doesn't mean the repertory
(i.e. which characters are included in that font).  That is
the same as any "ISO10646-1" fonts.  AFAIK, none of them
contain all of Unicode BMP characters.

Anyway, have you tried the latest code?  Does it still try
to display U+1F48 using the font "...-gb18030.2000-0"?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 10.01.2008 um 13:40 schrieb Kenichi Handa:

> Anyway, have you tried the latest code?  Does it still try
> to display U+1F48 using the font "...-gb18030.2000-0"?

I can't tell, because now it's just a box. And pressing C-u C-x = on  
that box gives the well-known

	describe-char-display: Format specifier doesn't match argument type

error. So a change has happened. Using the technique of loading descr- 
text.el leads to:


Debugger entered--Lisp error: (error "Format specifier doesn't match  
argument type")
   format("%04X%04X" "nil" nil)
   (setcdr char-font-info (format "%04X%04X" (cadr char-font-info)  
(cddr char-font-info)))
   (if (integerp (cdr char-font-info)) (setcdr char-font-info (format  
"%02X" ...)) (setcdr char-font-info (format "%04X%04X" ... ...)))
   (let ((char-font-info ...)) (if (integerp ...) (setcdr char-font- 
info ...) (setcdr char-font-info ...)) char-font-info)
   (if (display-graphic-p (selected-frame)) (let (...)  
(if ... ... ...) char-font-info) (let* (... ...) (if encoded ...)))
   describe-char-display(253851 8008)
   (let ((display ...)) (if (display-graphic-p ...) (if display ...  
"no font available") (if display ... "not encodable for terminal")))
   (cond (disp-vector (setq disp-vector ...) (dotimes ... ... ...)  
(format "by display table entry [%s] (see below)" ...)) (composition  
(let ... ... ... ... ... ...)) (t (let ... ...)))
   (list "display" (cond (disp-vector ... ... ...) (composition ...)  
(t ...)))
   (cons (list "display" (cond ... ... ...)) (append (let ... ...)  
(let ... ...)))
   (cons (cons "file code" (let* ... ...)) (cons (list "display" ...)  
(append ... ...)))
   (cons (list "buffer code" (encoded-string-description ... nil))  
(cons (cons "file code" ...) (cons ... ...)))
   (cons (cons "to input" (let ... ...)) (cons (list "buffer  
code" ...) (cons ... ...)))
   (cons (cons "category" (let ... ...)) (cons (cons "to input" ...)  
(cons ... ...)))
   (cons (list "syntax" (let ... ...)) (cons (cons "category" ...)  
(cons ... ...)))
   (cons (list "code point" (let ... ...)) (cons (list "syntax" ...)  
(cons ... ...)))
   (cons (list "preferred charset" (\` ...) (format "(%s)" ...))  
(cons (list "code point" ...) (cons ... ...)))
   (cons (list "character" (format "%s (%d, #o%o, #x%x)" ... char  
char char)) (cons (list "preferred charset" ... ...) (cons ... ...)))
   (backquote-list* (list "character" (format "%s (%d, #o%o, #x% 
x)" ... char char char)) (list "preferred charset" (\` ...) (format  
"(%s)" ...)) (list "code point" (let ... ...)) (list  
"syntax" (let ... ...)) (cons "category" (let ... ...)) (cons "to  
input" (let ... ...)) (list "buffer code" (encoded-string- 
description ... nil)) (cons "file code" (let* ... ...)) (list  
"display" (cond ... ... ...)) (append (let ... ...) (let ... ...)))
   (\` (("character" ...) ("preferred charset" ... ...) ("code  
point" ...) ("syntax" ...) ("category" ...) ("to input" ...) ("buffer  
code" ...) ("file code" ...) ("display" ...) (\,@ ...) (\,@ ...)))
   (setq item-list (\` (... ... ... ... ... ... ... ... ... ... ...)))
   (let* ((char ...) (charset ...) (composition ...) (component-chars  
nil) (display-table ...) (disp-vector ...) (multibyte-p enable- 
multibyte-characters) (overlays ...) (char-description ...) (text- 
props-desc ...) item-list max-width code) (setq code (encode-char  
char charset)) (setq item-list (\` ...)) (setq max-width  
(apply ... ...)) (help-setup-xref nil (interactive-p)) (with-help- 
window (help-buffer) (with-current-buffer standard- 
output ... ... ... ... ... ... ... ... ... ... ... ...)))
   describe-char(253851)
   what-cursor-position((4))
   call-interactively(what-cursor-position nil nil)

--
Greetings

   Pete

"What do you think of Western Civilisation?"
"I think it would be a good idea!"
				– Mohandas Karamchand Gandhi

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <37765195-4505-4662-AE93-5B78556F67F6@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> > Anyway, have you tried the latest code?  Does it still try
> > to display U+1F48 using the font "...-gb18030.2000-0"?

> I can't tell, because now it's just a box. And pressing C-u C-x = on  
> that box gives the well-known

> 	describe-char-display: Format specifier doesn't match argument type

Oops, sorry.  I installed a fix.

I also installed a feature to use the specified font for all
Latin characters.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 14.01.2008 um 02:36 schrieb Kenichi Handa:

> I installed a fix.
>
> I also installed a feature to use the specified font for all
> Latin characters.


Compiled to use GTK and font-backend, although the latter is disabled  
via an X resource, this version is almost unusable: it takes endless  
time to perform an isearch or quit it. The X server too consumes lots  
of CPU power that no time is left for other processes.

Almost no open box symbol appears, which is simply great, but I am  
not completely sure whether the contents of the braces is always  
right (I am using utf8.txt from the Kermit distribution). I'll check  
it when GNU Emacs runs as lightly as previously, with an Apple Mac OS  
X utility, the Character Palette – or the third party  
UnicodeChecker, which does not seem to waste or need as many resources.

I'll try to re-configure and re-compile to find a variant that does  
not consume all CPU power!

--
Greetings

   Pete

A mathematician is a device for turning coffee into theorems.
				– Erdős Pál

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]


Am 14.01.2008 um 02:36 schrieb Kenichi Handa:

> I installed a fix.
>
> I also installed a feature to use the specified font for all
> Latin characters.

Not configuring with font-backend seems to make GNU Emacs behave as  
fast as usual. Many open boxes appear, the size of the glyphs found  
varies since different fonts are used. Now U+1F48 is taken from      - 
MUTT-ClearlyU-Medium-R-Normal--17-120-100-100-P-123-ISO10646-1  
(#x1F48). C-u C-x = still reports:

	preferred charset: gb18030 (GB18030)

or, complete:

	        character: Ὀ (8008, #o17510, #x1f48)
	preferred charset: gb18030 (GB18030)
	       code point: 0x81369132
	           syntax: w 	which means: word
	         category: g:Greek
	      buffer code: #xE1 #xBD #x88
	        file code: #xE1 #xBD #x88 (encoded by coding system utf-8-unix)
	          display: by this font (glyph code)
	     -MUTT-ClearlyU-Medium-R-Normal--17-120-100-100-P-123-ISO10646-1  
(#x1F48)
	
	Character code properties are not shown: customize what to show
	
	There are text properties here:
	  auto-composed        t

It's definitely the enabled font-backend that consumes so much CPU  
power. With this enabled the HELLO looks a bit alien (left with font- 
backend, in the middle GNU Emacs 23.0.60 from ten days ago, right  
Emacs.app, the Cocoa variant):


[-- Attachment #2: HELLOmin.png --]
[-- Type: image/png, Size: 133954 bytes --]

[-- Attachment #3: Type: text/plain, Size: 159 bytes --]



And here is the start when the glyphs are not lined up correctly and  
do not seem to be the right ones (left window is from UnicodeChecker  
application):


[-- Attachment #4: artifactMIN.png --]
[-- Type: image/png, Size: 15188 bytes --]

[-- Attachment #5: Type: text/plain, Size: 575 bytes --]



The character info returned looks also strange. Finally a bit ps output:

   UID   PID  PPID CPU PRI NI      VSZ    RSS WCHAN  STAT  TT        
TIME COMMAND
   501   839   816   0  31  0   113432  43980 -      S     ??     
9:37.04 /usr/local/bin/emacs-23.0.60 -geometry 100x57+666+136
   501  4017   882   0  30  0   121684  42144 -      R     p7     
1:25.70 src/emacs -Q

The GNU Emacs with PID 839 is running since a few days, the other  
since a few minutes ...

--
Greetings

   Pete

Behold the warranty ... the bold print giveth and the fine print  
taketh away.



[-- Attachment #6: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <7A846B7D-1005-463E-B704-81895DD7FBDC@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Am 14.01.2008 um 02:36 schrieb Kenichi Handa:

> > I installed a fix.
> >
> > I also installed a feature to use the specified font for all
> > Latin characters.

> Compiled to use GTK and font-backend, although the latter is disabled  
> via an X resource, this version is almost unusable: it takes endless  
> time to perform an isearch or quit it. The X server too consumes lots  
> of CPU power that no time is left for other processes.

Did that slowness happen only after my recent change?  And,
how did you disable font-backend via an X resource"?  As far
as I remember, you can't do it.  Via X resouce, you can only
specify which font backend to use.  If you configure Emacs
with --enable-font-backend, the only way to suppress it is
by the command line argument "--disable-font-backend".

> Almost no open box symbol appears, which is simply great, but I am  
> not completely sure whether the contents of the braces is always  
> right (I am using utf8.txt from the Kermit distribution).

What is "the contents of the braces"?

> I'll check  
> it when GNU Emacs runs as lightly as previously, with an Apple Mac OS  
> X utility, the Character Palette – the third party  
> UnicodeChecker, which does not seem to waste or need as many resources.

> I'll try to re-configure and re-compile to find a variant that does  
> not consume all CPU power!

Thank you. 

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 15.01.2008 um 09:18 schrieb Kenichi Handa:

> Did that slowness happen only after my recent change?

Yes. Could it was introduced before, but for me it became existing  
when I updated after receiving your eMail yesterday.

> And, how did you disable font-backend via an X resource"?

Probably badly expressed. I have two lines in ~/.Xdefaults:

	Emacs.FontBackend:              x
	!Emacs.FontBackend:             xft

When the xft option is on, GNU Emacs crashes during start-up.


> As far as I remember, you can't do it.  Via X resouce, you can only
> specify which font backend to use.  If you configure Emacs
> with --enable-font-backend, the only way to suppress it is
> by the command line argument "--disable-font-backend".

When using this option on the command line, GNU Emacs works much  
faster, when I've configure it before with --enable-font-backend. It  
scrolls up or down at normal speed. And there is one more difference:  
I can see a file name like

	RGB äöüæÆÜÖÄ Kopie.txt

as

	RGB äöüæÆÜÖÄ Kopie.txt

while it otherwise is displayed as

	RGB aouæÆUOA Kopie.txt

>
>> Almost no open box symbol appears, which is simply great, but I am
>> not completely sure whether the contents of the braces is always
>> right (I am using utf8.txt from the Kermit distribution).
>
> What is "the contents of the braces"?


The character as described outside. For example:

	[Ȫ]  022A  LATIN CAPITAL LETTER O WITH DIAERESIS AND MACRON
	[ȫ]  022B  LATIN SMALL LETTER O WITH DIAERESIS AND MACRON
	[Ȭ]  022C  LATIN CAPITAL LETTER O WITH TILDE AND MACRON
	[ȭ]  022D  LATIN SMALL LETTER O WITH TILDE AND MACRON
	[Ȯ]  022E  LATIN CAPITAL LETTER O WITH DOT ABOVE
	[ȯ]  022F  LATIN SMALL LETTER O WITH DOT ABOVE
	[Ȱ]  0230  LATIN CAPITAL LETTER O WITH DOT ABOVE AND MACRON
	[ȱ]  0231  LATIN SMALL LETTER O WITH DOT ABOVE AND MACRON

It's this file: ftp://kermit.columbia.edu/kermit/charsets/utf8.txt

--
Greetings

   Pete

Our enemies are innovative and resourceful, and so are we. They never  
stop thinking about new ways to harm our country and our people, and  
neither do we.
				– Georges W. Bush

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <7A846B7D-1005-463E-B704-81895DD7FBDC@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Compiled to use GTK and font-backend, although the latter is disabled  
> via an X resource, this version is almost unusable: it takes endless  
> time to perform an isearch or quit it. The X server too consumes lots  
> of CPU power that no time is left for other processes.

Does this slowness happen for all windows, or only for a
window showing non-ASCII characters?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 16.01.2008 um 07:38 schrieb Kenichi Handa:

> Does this slowness happen for all windows, or only for a
> window showing non-ASCII characters?


It happens when it comes to displaying a non-ASCII character. Then  
scrolling through my home directory stops for seconds then. And again  
when the next file name with ä, ö, ü, etc. would become displayed.  
Scrolling through the configure script or ChangeLog file is quite  
fast, as usual.

--
Greetings

   Pete

To be is to do.
			– I. Kant
To do is to be.
			– A. Sartre
Yabba-Dabba-Doo!
			– F. Flintstone

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 15.01.2008 um 09:18 schrieb Kenichi Handa:

> Did that slowness happen only after my recent change?


I installed an update from CVS on the weekend. I tried to improve  
compilation and configuration. Then I stopped times.

Launching with '-Q --disable-font-backend' it takes 25 sec to become  
ready, 10 sec to perform C-h H, and 2 sec to scroll forward.

Launching without '--disable-font-backend' it takes 25 sec to become  
ready, then it takes almost 2 min until text from C-h H appears, and  
then it takes another 7 min until the hollow cursor is filled and GNU  
Emacs accepts input. Scroll-forward takes over 2 min. Quitting, C-x  
c, takes almost 4 min ...

With ``-J:%%-   HELLO   ´´ starts mode-line when launched without '-- 
disable-font-backend.' With this option mode-line starts with: ``-J:% 
*-   HELLO   ´´ and when quitting GNU Emacs asks whether saving HELLO.

In GNU Emacs 23.0.60.1 (powerpc-apple-darwin8.11.0, GTK+ Version 2.6.10)
  of 2008-01-27 on Latsche.local
Windowing system distributor `The XFree86 Project, Inc', version  
11.0.40400000
configured using `configure  '--enable-font-backend' '--with-x- 
toolkit=gtk' '--with-dbus' '--without-pop' '--without-sound' '-- 
enable-locallisppath=/Library/Application Support/Emacs/calendar22:/ 
Library/Application Support/Emacs/caml:/Library/Application Support/ 
Emacs:/sw/share/emacs21/site-lisp/elib' 'PKG_CONFIG_PATH=/sw/lib/ 
freetype219/lib/pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/ 
pkgconfig:/sw/share/pkgconfig:/usr/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/X11R6/lib/pkgconfig' 'CPPFLAGS=-no-cpp-precomp - 
D__BIND_NOSTATIC -I/usr/include/openssl -I/sw/include/pango-1.0 -I/sw/ 
lib/fontconfig2/include -I/sw/lib/freetype219/include -I/sw/lib/ 
freetype219/include/freetype2 -I/sw/include -I/usr/local/include - 
idirafter /usr/X11R6/include' 'CFLAGS=-ggdb -gfull -Wno-pointer-sign - 
bind_at_load -pipe -fPIC -mcpu=7450 -mtune=7450 -fast' 'LDFLAGS=- 
dead_strip -multiply_defined suppress -L/sw/lib/ncurses -L/sw/lib/ 
fontconfig2/lib -L/sw/lib/freetype219/lib -L/sw/lib -L/usr/local/lib - 
L/usr/X11R6/lib''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: nil
   value of $LC_CTYPE: de_DE.UTF-8
   value of $LC_MESSAGES: nil
   value of $LC_MONETARY: nil
   value of $LC_NUMERIC: nil
   value of $LC_TIME: nil
   value of $LANG: de_DE.UTF-8
   value of $XMODIFIERS: nil
   locale-coding-system: utf-8-unix
   default-enable-multibyte-characters: t


(C debugging is enabled because both, GNU Emacs 23.0.60 and 23.0.50,  
show crashes when I insert with the mouse text I copied before with  
the mouse. Could be it happens only in situations when Mac OS X uses  
more than 2 GB of allocated swap space on disk, on a different volume/ 
slice/partition.)

--
Greetings

   Pete

There's something the technicians need to learn from the artists. If  
it isn't aesthetically pleasing, it's probably wrong.

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <21707F94-9353-4F39-814B-F10146374B18@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Launching with '-Q --disable-font-backend' it takes 25 sec to become  
> ready, 10 sec to perform C-h H, and 2 sec to scroll forward.

> Launching without '--disable-font-backend' it takes 25 sec to become  
> ready, then it takes almost 2 min until text from C-h H appears, and  
> then it takes another 7 min until the hollow cursor is filled and GNU  
> Emacs accepts input. Scroll-forward takes over 2 min. Quitting, C-x  
> c, takes almost 4 min ...

I've just committed a change that suppresses exhaustive font
search.  Do you see any improvement with the latest code?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 30.01.2008 um 07:25 schrieb Kenichi Handa:

> I've just committed a change that suppresses exhaustive font
> search.  Do you see any improvement with the latest code?


Yes, it is now as fast as if started with --disable-font-backend, but  
the window opens (again) as a very small one:

   Corners:  +113+33  -1129+33  -1129-675  +113-675
   -geometry 27x15+111+11

Correct would be, from ~/.Xdefaults (Emacs*geometry: 97x53+111+11):

   Corners:  +113+33  -709+33  -709-257  +113-257
   -geometry 97x53+111+11

GNU Emacs does not change the HELLO buffer, they have different  
looks, depending on the number of fonts found.

--
Greetings

   Pete

The problem with the French is that they don't have a word for «  
entrepreneur ».
				– George W. Bush

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <75C1B4E4-16F3-44A0-8053-79B4414598F6@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

> Yes, it is now as fast as if started with --disable-font-backend, but  
> the window opens (again) as a very small one:

>    Corners:  +113+33  -1129+33  -1129-675  +113-675
>    -geometry 27x15+111+11

> Correct would be, from ~/.Xdefaults (Emacs*geometry: 97x53+111+11):

>    Corners:  +113+33  -709+33  -709-257  +113-257
>    -geometry 97x53+111+11

Is it a new problem?  Doesn't it happen with Emacs 22?

> GNU Emacs does not change the HELLO buffer, they have different  
> looks, depending on the number of fonts found.

I don't understand what you mean.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 31.01.2008 um 02:19 schrieb Kenichi Handa:

>
>> Yes, it is now as fast as if started with --disable-font-backend, but
>> the window opens (again) as a very small one:
>
>>    Corners:  +113+33  -1129+33  -1129-675  +113-675
>>    -geometry 27x15+111+11
>
>> Correct would be, from ~/.Xdefaults (Emacs*geometry: 97x53+111+11):
>
>>    Corners:  +113+33  -709+33  -709-257  +113-257
>>    -geometry 97x53+111+11
>
> Is it a new problem?  Doesn't it happen with Emacs 22?

This is a new problem and it does not happen with GNU Emacsen 22.1.50  
and 23.0.50.

>
>> GNU Emacs does not change the HELLO buffer, they have different
>> looks, depending on the number of fonts found.
>
> I don't understand what you mean.
>

Before, when GNU Emacs 23.0.60 was launched with font-backend  
disabled it polluted and changed somehow the HELLO buffer, as I  
reported. This does not happen anymore. Still GNU Emacs with enabled  
font-backend shows less non-Latin glyphs.

--
Greetings

   Pete

Let's face it; we don't want a free market economy either.
		– James Farley, president, Coca-Cola Export Corp., 1959

Re: 23.0.60; describe-char gives wrong information

[Kenichi Handa]

In article <C2442D12-1BB6-44EB-9232-014C05C55769@Freenet.DE>, Peter Dyballa <Peter_Dyballa@Freenet.DE> writes:

>>> Yes, it is now as fast as if started with --disable-font-backend, but
>>> the window opens (again) as a very small one:
> >
>>> Corners:  +113+33  -1129+33  -1129-675  +113-675
>>> -geometry 27x15+111+11
> >
>>> Correct would be, from ~/.Xdefaults (Emacs*geometry: 97x53+111+11):
> >
>>> Corners:  +113+33  -709+33  -709-257  +113-257
>>> -geometry 97x53+111+11
> >
> > Is it a new problem?  Doesn't it happen with Emacs 22?

> This is a new problem and it does not happen with GNU Emacsen 22.1.50  
> and 23.0.50.

Please show me the result of M-x describe-face RET default RET.

>>> GNU Emacs does not change the HELLO buffer, they have different
>>> looks, depending on the number of fonts found.
> >
> > I don't understand what you mean.
> >

> Before, when GNU Emacs 23.0.60 was launched with font-backend  
> disabled it polluted and changed somehow the HELLO buffer, as I  
> reported.

It sees that I missed your report about HELLO file.  You
wrote "polluted and changed", but what they exactly mean?
"changed" from what?

> This does not happen anymore. Still GNU Emacs with enabled  
> font-backend shows less non-Latin glyphs.

Please show me a concrete example.  If Emacs without
font-backend shows a correct glyph for character CH, and
Emacs with font-backend doesn't, please show me the result
of C-u C-x = on that character by Emacs without
font-backend.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 01.02.2008 um 06:08 schrieb Kenichi Handa:

>> This is a new problem and it does not happen with GNU Emacsen 22.1.50
>> and 23.0.50.
>
> Please show me the result of M-x describe-face RET default RET.

It's a bit puzzling! Now that I have the test cast for the Apple bug  
report compiled

	configured using `configure  '--enable-font-backend' '--with- 
freetype' '--with-xft' '--with-x-toolkit=lucid' '--without-xaw3d' '-- 
without-libotf' '--without-jpeg' '--without-tiff' '--without-gif' '-- 
without-png' '--without-rsvg' '--without-pop' '--without-sound' '-- 
enable-locallisppath=/Library/Application Support/Emacs/calendar22:/ 
Library/Application Support/Emacs/caml:/Library/Application Support/ 
Emacs:/sw/share/emacs21/site-lisp/elib' 'PKG_CONFIG_PATH=/sw/lib/ 
freetype219/lib/pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/ 
pkgconfig:/sw/share/pkgconfig:/usr/lib/pkgconfig:/usr/local/lib/ 
pkgconfig:/usr/X11R6/lib/pkgconfig' 'CPPFLAGS=-no-cpp-precomp - 
D__BIND_NOSTATIC' 'CFLAGS=-H -Wno-pointer-sign -bind_at_load -pipe - 
fPIC -mcpu=7450 -mtune=7450 -O0' 'LDFLAGS=-dead_strip - 
multiply_defined suppress -L/sw/lib/fontconfig2/lib -L/sw/lib/ 
freetype219/lib''

it launches normal. Describe-face gives:

Face: default (sample) (customize this face)
Documentation: Basic default face.
Defined in `faces.el'.

         Family: b&h-lucidatypewriter
          Width: normal
         Height: 96
         Weight: normal
          Slant: normal
     Foreground: Black
     Background: AliceBlue
      Underline: nil
       Overline: nil
Strike-through: nil
            Box: nil
        Inverse: nil
        Stipple: nil
           Font: -B&H-LucidaTypewriter-Medium-R-Normal- 
Sans-10-100-75-75-M-60-ISO8859-1
        Fontset: -b&h-lucidatypewriter-medium-r-normal- 
sans-10-100-75-75-m-60-fontset-auto1
        Inherit: unspecified

The GNU Emacs 23.0.60 I use regularly is

	configured using `configure '--with-x-toolkit=lucid' '--without-gtk'  
'--with-dbus' '--without-sound' '--without-pop' '--with-xpm' '--with- 
jpeg' '--with-tiff' '--with-gif' '--with-png' '--enable- 
locallisppath=/Library/Application Support/Emacs/calendar22:/Library/ 
Application Support/Emacs/caml:/Library/Application Support/Emacs:/sw/ 
share/emacs21/site-lisp/elib' 'PKG_CONFIG_PATH=/sw/lib/freetype219/ 
lib/pkgconfig:/sw/lib/fontconfig2/lib/pkgconfig:/sw/lib/pkgconfig:/sw/ 
lib/system-openssl/lib/pkgconfig:/sw/share/pkgconfig:/usr/lib/ 
pkgconfig:/usr/local/lib/pkgconfig:/usr/local/clamXav/lib/pkgconfig:/ 
usr/local/lib/pkgconfig' 'CPPFLAGS=-no-cpp-precomp -D__BIND_NOSTATIC - 
I/usr/include/openssl -I/sw/include/pango-1.0 -I/sw/lib/fontconfig2/ 
include -I/sw/lib/freetype219/include -I/sw/lib/freetype219/include/ 
freetype2 -I/sw/include -I/usr/local/include -idirafter /usr/X11R6/ 
include' 'CXXFLAGS=-no-cpp-precomp -I/usr/include/openssl -I/sw/ 
include/pango-1.0 -I/sw/lib/fontconfig2/include -I/sw/lib/freetype219/ 
include -I/sw/lib/freetype219/include/freetype2 -I/sw/include -I/usr/ 
local/include' 'CFLAGS=-bind_at_load -pipe -fPIC -mcpu=7450 - 
mtune=7450 -fast -mpim-altivec -ftree-vectorize -foptimize-register- 
move -freorder-blocks -freorder-blocks-and-partition -fthread-jumps - 
fpeephole -fno-crossjumping -Wno-pointer-sign' 'LDFLAGS=-dead_strip - 
multiply_defined suppress -L/sw/lib/ncurses -L/sw/lib/fontconfig2/lib  
-L/sw/lib/freetype219/lib -L/sw/lib -L/usr/local/lib -L/usr/X11R6/lib''

and describe-face gives:

Face: default (sample) (customize this face)
Documentation: Basic default face.
Defined in `faces.el'.

         Family: b&h-lucidatypewriter
          Width: normal
         Height: 125
         Weight: normal
          Slant: normal
     Foreground: Black
     Background: AliceBlue
      Underline: nil
       Overline: nil
Strike-through: nil
            Box: nil
        Inverse: nil
        Stipple: nil
           Font: -b&h-lucidatypewriter-medium-r-normal- 
sans-13-120-75-75-m-70-iso10646-1
        Fontset: -b&h-lucidatypewriter-medium-r-normal- 
sans-12-120-75-75-m-70-fontset-auto1
        Inherit: unspecified

I'll re-configure and re-compile to produce the dwarf Emacs!

>>>>
> It sees that I missed your report about HELLO file.  You
> wrote "polluted and changed", but what they exactly mean?
> "changed" from what?

I can't describe it! The look of the HELLO buffer did not appear to  
me changed in any way. It was only in mode-line visible that it was  
changed. And a #HELLO# file was left. I could reproduce this when GNU  
Emacs had the code with the lots of font lookups that made it so slow.

Right now I've seen in echo area a message, and *Messages* contains:

	Note: file is write protected
	View mode: type C-h for help, h for commands, q to quit.
	Error during redisplay: (wrong-type-argument font nil)
	Loading /usr/local/share/emacs/23.0.60/lisp/international/uni- 
name.el (source)...done
	Error during redisplay: (wrong-type-argument font nil) [12 times]
	Auto-saving...
	Auto-saving HELLO: Opening output file: permission denied, /usr/ 
local/share/emacs/23.0.60/etc/#HELLO#
	Error during redisplay: (wrong-type-argument font nil) [3 times]
	Auto-saving...done
	Error during redisplay: (wrong-type-argument font nil) [13 times]

The message comes when I am not using the HELLO buffer (actually I am  
writing this text in Mail). What can also observe in my production  
GNU Emacs 23.0.60 is that the look in the HELLO buffer changes when I  
move the cursor. Right now it is at the end of the Czech greetings  
and I see five Braille characters. When I move it the end of the  
Braille word (hello?), boxes appear instead. After some time in echo- 
area a message is shown about inability to save – and the Braille  
glyphs are back. A similiar effect happens at the end of the Amharic  
or Arabic greetings.

>
>> This does not happen anymore. Still GNU Emacs with enabled
>> font-backend shows less non-Latin glyphs.
>
> Please show me a concrete example.  If Emacs without
> font-backend shows a correct glyph for character CH, and
> Emacs with font-backend doesn't, please show me the result
> of C-u C-x = on that character by Emacs without

In the header, in the  South East Asia line, in the middle text,  
between Lao and Thai, only boxes are shown, three to the left, in the  
middle a "text" representing ZWJ, and five boxes to the right. The  
production version shows on this line only Lao, Thai, Vietnamese.  
Later no mentioning of Myanmar and Khmer. In the production Emacs  
some non-Latin texts are hard to reach because these texts change  
when the cursor is put on them ...

Differences are in IPA English, visible in up-to-date Apple debug  
version:

	        character: ʃ (643, #o1203, #x283)
	preferred charset: gb18030 (GB18030)
	       code point: 0x8130B036
	           syntax: w 	which means: word
	         category: j:Japanese l:Latin
	      buffer code: #xCA #x83
	        file code: ESC #x24 #x28 #x51 #x2A #x68 (encoded by coding  
system iso-2022-7bit-unix)
	          display: by this font (glyph code)
	     -MUTT-ClearlyU-Medium-R-Normal--17-120-100-100-P-123-ISO10646-1  
(#x283)
	
	Character code properties are not shown: customize what to show
	
	There are text properties here:
	  auto-composed        t
	  charset              japanese-jisx0213-1

and invisible in elder production version:

	        character: ʃ (643, #o1203, #x283)
	preferred charset: gb18030 (GB18030)
	       code point: 0x8130B036
	           syntax: w 	which means: word
	         category: j:Japanese l:Latin
	      buffer code: #xCA #x83
	        file code: ESC #x24 #x28 #x51 #x2A #x68 (encoded by coding  
system iso-2022-7bit-unix)
	          display: by this font (glyph code)
	     -monotype-arial unicode ms-medium-r-normal--13-127-74-74-p-129- 
gb18030.2000-0 (#xB036)
	
	Character code properties are not shown: customize what to show
	
	There are text properties here:
	  auto-composed        t
	  charset              japanese-jisx0213-1


--
Greetings

   Pete

Email is a wonderful thing for people whose role in life is to be on  
top of things. But not for me; my role is to be on the bottom of  
things. What I do takes long hours of studying and uninterruptible  
concentration.
				– Donald Knuth

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 01.02.2008 um 06:08 schrieb Kenichi Handa:

>>>> Yes, it is now as fast as if started with --disable-font- 
>>>> backend, but
>>>> the window opens (again) as a very small one:
>>>
>>>> Corners:  +113+33  -1129+33  -1129-675  +113-675
>>>> -geometry 27x15+111+11
>>>
>>>> Correct would be, from ~/.Xdefaults (Emacs*geometry: 97x53+111+11):
>>>
>>>> Corners:  +113+33  -709+33  -709-257  +113-257
>>>> -geometry 97x53+111+11
>>>
>>> Is it a new problem?  Doesn't it happen with Emacs 22?
>
>> This is a new problem and it does not happen with GNU Emacsen 22.1.50
>> and 23.0.50.
>
> Please show me the result of M-x describe-face RET default RET.


I seem to be unable to reproduce this! I'll check the eMails I've  
sent to find the original configuration (upon recommendation from a  
third side I changed GCC optimisation flags and then I also  
simplified a few *FLAG values). Maybe a 'make bootstrap' or maximal  
optimisation are needed – or both!

--
Greetings

              ~  O
   Pete       ~~_\\_/%
              ~  O  o

Re: 23.0.60; describe-char gives wrong information

[Peter Dyballa]

Am 01.02.2008 um 13:27 schrieb Peter Dyballa:

> Am 01.02.2008 um 06:08 schrieb Kenichi Handa:
>
>>>>> Yes, it is now as fast as if started with --disable-font- 
>>>>> backend, but
>>>>> the window opens (again) as a very small one:
>>>>
>>>>> Corners:  +113+33  -1129+33  -1129-675  +113-675
>>>>> -geometry 27x15+111+11
>>>>
>>>>> Correct would be, from ~/.Xdefaults (Emacs*geometry: 97x53+111 
>>>>> +11):
>>>>
>>>>> Corners:  +113+33  -709+33  -709-257  +113-257
>>>>> -geometry 97x53+111+11
>>>>
>>>> Is it a new problem?  Doesn't it happen with Emacs 22?
>>
>>> This is a new problem and it does not happen with GNU Emacsen  
>>> 22.1.50
>>> and 23.0.50.
>>
>> Please show me the result of M-x describe-face RET default RET.
>
>
> I seem to be unable to reproduce this!

Now I could – as a kind of side-effect, with enabled font backend  
(x,ftx). The original cause seems to be a crash of GNU Emacs 23.0.60  
(bus error, I'll prepare a bug report) from today's sources in GTK  
clothes. While Mac OS X was writing a core file, examining it and  
preparing a bug report for Apple, I already launched GNU Emacs again  
to see whether it crashes when I use xkill to finish it. And this  
race condition (?) it came up that small. The fontset used *looks*  
like my default from initial-frame-alist but is called different: - 
b&h-lucidatypewriter-medium-r-normal-sans-10-*-*-*-*-*-fontset- 
startup. The next frame follows default-frame-alist.

--
Greetings

   Pete

Either this man is dead or my watch has stopped.
				- Groucho Marx