bug#251: marked as done (compose-char is buggy on Windows)

[Emacs bug Tracking System]

Your message dated Fri, 01 Aug 2008 16:09:15 +0100
with message-id <4893271B.6080002@gnu.org>
and subject line Re: compose-char is buggy on Windows
has caused the Emacs bug report #251,
regarding compose-char is buggy on Windows
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
251: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=251
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> compose-char is buggy on Windows
>
>
>
>
> Date: 
>
> Sat, 05 Jan 2008 21:51:05 +0100
>
>
>
>
> User-agent: 
>
> SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō)	APEL/10.7 Emacs/22.1 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI)
>
>
>
>
> The compose-char function seems to have problems on Windows. For
> example, if you try the following:
>
>   (compose-region 1 5 (decode-char 'ucs #x221E))
>
> Emacs should display the first few characters of the buffer as an
> infinity symbol (Unicode #x221E). Instead, it produces some garbled
> character. On GNU/Linux (both console and GTK interface), this works.
>
> This happens for most but not all characters: if I try this trick with
> a latin-1 character, it works right. For fancy Unicode symbols, it
> never seems to work. This doesn't seem to depend on the font
> used. 
>
> In GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600)
>  of 2007-06-02 on RELEASE
> Windowing system distributor `Microsoft Corp.', version 5.1.2600
> configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'
>
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: nil
>   value of $LC_CTYPE: nil
>   value of $LC_MESSAGES: nil
>   value of $LC_MONETARY: nil
>   value of $LC_NUMERIC: nil
>   value of $LC_TIME: nil
>   value of $LANG: NLB
>   locale-coding-system: cp1252
>   default-enable-multibyte-characters: t
>
> Major mode: Lisp Interaction
>
> Minor modes in effect:
>   encoded-kbd-mode: t
>   tooltip-mode: t
>   tool-bar-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
>   unify-8859-on-encoding-mode: t
>   utf-translate-cjk-mode: t
>   auto-compression-mode: t
>   line-number-mode: t
>
> Recent input:
> M-x r e p o r t SPC e m SPC b SPC <return>
>
> Recent messages:
> ("C:\\Documents and Settings\\Peter\\Bureaublad\\emacs-22.1\\bin\\emacs.exe")
> Loading encoded-kb...done
> For information about the GNU Project and its goals, type C-h C-p. [2 times]
> Loading emacsbug...
> Loading regexp-opt...done
> Loading emacsbug...done
>
>
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: compose-char is buggy on Windows
>
>
>
>
> Date: 
>
> Fri, 01 Aug 2008 16:09:15 +0100
>
>
>
>
> User-agent: 
>
> Thunderbird 2.0.0.16 (Windows/20080708)
>
>
>
>
> > The compose-char function seems to have problems on Windows. For
> > example, if you try the following:
> > 
> >   (compose-region 1 5 (decode-char 'ucs #x221E))
> > 
> > Emacs should display the first few characters of the buffer as an
> > infinity symbol (Unicode #x221E). Instead, it produces some garbled
> > character.
>
> This bug has been fixed for 22.3.
>
>
> --- End Message ---