bug#12948: 24.1; wrong angle brackets

bug#12948: 24.1; wrong angle brackets

[Mattias Engdegård]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

With the TeX input method, \langle and \rangle yield the deprecated
characters U+2329 and U+232A rather than the ones at U+27E8 and U+27E9
which are for mathematical use and Western languages. The former
characters should not be used; they are troublesome because of their
canonical equivalence to CJK punctuation, and are frequently rendered
(correctly) as having the full width of a CJK character.

These definitions are in leim/quail/latin-ltx.el. The same file also
produces the deprecated angle brackets from \leftparengtr and
\rightparengtr, but this makes even less sense, since those names should
properly be used for U+2993 and U+2994, unless I'm completely mistaken.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
     `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/local/emacs/24.1/share/emacs/24.1/etc/DEBUG.


In GNU Emacs 24.1.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll  
bars)
  of 2012-07-30 on bach
Windowing system distributor `The X.Org Foundation', version  
11.0.11003000
Configured using:
  `configure 'CC=/usr/local/gcc/4.3.4/bin/gcc'
  '--prefix=/usr/local/emacs/24.1''

Important settings:
   value of $LC_ALL: nil
   value of $LC_COLLATE: C
   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: sv_SE.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:
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
M-x r e p o r t SPC e m SPC SPC <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer loaddefs button faces cus-face files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dynamic-setting
font-render-setting x-toolkit x multi-tty emacs)

bug#12948: 24.1; wrong angle brackets

[Stefan Monnier]

> With the TeX input method, \langle and \rangle yield the deprecated
> characters U+2329 and U+232A rather than the ones at U+27E8 and U+27E9
> which are for mathematical use and Western languages.  The former
> characters should not be used; they are troublesome because of their
> canonical equivalence to CJK punctuation, and are frequently rendered
> (correctly) as having the full width of a CJK character.

Sounds OK.  BTW why not 3008 and 3009 instead?

> These definitions are in leim/quail/latin-ltx.el. The same file also
> produces the deprecated angle brackets from \leftparengtr and
> \rightparengtr, but this makes even less sense, since those names should
> properly be used for U+2993 and U+2994, unless I'm completely mistaken.

This is less clear.  I can't find any of \leftparengtr or \rightparengtr
in any TeX package on my system.  Searching for them on the web, leads
to more confusion.  Basically, I think that 2994 for \rightparengtr
would be OK (tho it seems that there's a TeX package that provides it
under the name \rparengtr), but for \leftparengtr
http://www.w3.org/Math/characters/iso8879/isoamsc.html seems to suggest
that 29a0 is a better choice (after all, 2993 is a left paren with
a "less-than" rather than "greater-than" in it).

WDYT?


        Stefan

bug#12948: 24.1; wrong angle brackets

[Mattias Engdegård]

[ Sorry about the duplicate; now the right recipients ]

23 nov 2012 kl. 22.15 skrev Stefan Monnier:

>> With the TeX input method, \langle and \rangle yield the deprecated
>> characters U+2329 and U+232A rather than the ones at U+27E8 and U 
>> +27E9
>> which are for mathematical use and Western languages.  The former
>> characters should not be used; they are troublesome because of their
>> canonical equivalence to CJK punctuation, and are frequently rendered
>> (correctly) as having the full width of a CJK character.
>
> Sounds OK.  BTW why not 3008 and 3009 instead?

U+3008 and U+3009 are the CJK brackets that U+2329 and U+232A are  
canonically equivalent to. They are full-width, so they don't go well  
typographically with Western languages or formal notation, where use  
of \rangle and \langle is intended. There could also be other  
differences in appearance (stroke width, height and so on).

>> These definitions are in leim/quail/latin-ltx.el. The same file also
>> produces the deprecated angle brackets from \leftparengtr and
>> \rightparengtr, but this makes even less sense, since those names  
>> should
>> properly be used for U+2993 and U+2994, unless I'm completely  
>> mistaken.
>
> This is less clear.  I can't find any of \leftparengtr or  
> \rightparengtr
> in any TeX package on my system.  Searching for them on the web, leads
> to more confusion.  Basically, I think that 2994 for \rightparengtr
> would be OK (tho it seems that there's a TeX package that provides it
> under the name \rparengtr), but for \leftparengtr
> http://www.w3.org/Math/characters/iso8879/isoamsc.html seems to  
> suggest
> that 29a0 is a better choice (after all, 2993 is a left paren with
> a "less-than" rather than "greater-than" in it).

Yes, you are probably right, but it's not crystal clear. U+2994 and U 
+29A0 seem accurate at first blush, but the Unicode reference chart (http://www.unicode.org/charts/PDF/U2980.pdf 
) does not render them in a way that suggests any relation between them.

U+2993 and U+2994 are more obviously rendered as a pair, but as you  
say the name \leftparengtr would not make sense for U+2993. By the  
way, the mirror of U+29A0 is U+2222, which in TeX is \sphericalangle.  
In addition, the Unicode metadata marks U+2994 as a closing paired  
delimiter and U+2993 as an opening one. U+29A0 and U+2222 are just  
marked as symbols.

If I were emperor of Emacs, I would delete them from latin-ltx.el and  
ask anyone who complains to give references, but if you prefer to keep  
them but changed to U+2994 and U+29A0 (which are the only characters  
that make sense after all), then please do so. The current definitions  
are clearly wrong.

> WDYT?

Sorry, I didn't understand that.

bug#12948: 24.1; wrong angle brackets

[Stefan Monnier]

>> Sounds OK.  BTW why not 3008 and 3009 instead?
> U+3008 and U+3009 are the CJK brackets that U+2329 and U+232A are
> canonically equivalent to.

OK, done.

> If I were emperor of Emacs, I would delete them from latin-ltx.el and ask
> anyone who complains to give references, but if you prefer to keep them but
> changed to U+2994 and U+29A0 (which are the only characters that make sense
> after all), then please do so. The current definitions are clearly wrong.

Not being an emperor, I deleted them but I won't ask people to complain.

Thank you,


        Stefan