bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Emacs bug Tracking System
Subject: bug#251: marked as done (compose-char is buggy on Windows)
Date: Fri, 1 Aug 2008 08:15:04 -0700

Your message dated Fri, 01 Aug 2008 16:09:15 +0100
with message-id <address@hidden>
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 address@hidden
immediately.)


-- 
251: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=251
Emacs Bug Tracking System
Contact address@hidden 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 ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]