keysymdef.h has wrong implies symbol? → please fix that

[Peter Hutterer]

On Tue, Jan 06, 2009 at 09:38:19AM +0100, Erik Streb del Toro wrote:
> Please do something. Or tell my what keeps you from correcting this? As  
> Simon wrote, it was only a conversion error:

Pushed as 091c1624fd2f9d933329d6152e4ecd865aa7903a. Sorry, sometimes things
fall under the radar. Thanks for reminding me though.

Cheers,
  Peter

> Simos Xenitellis schrieb am 27.10.2008 12:14:
>> keysyms and Unicode characters. This mapping apparently originates
>> from the work of Marcus Kuhn,a copy of which is at
>> http://www.cl.cam.ac.uk/~mgk25/ucs/keysyms.txt
>>
>> I checked the gtk+ commit logs that go back to 2000, and I see that still it was
>>
>>   { 0x08ce, 0x21d2 }, /*                     implies ⇒ RIGHTWARDS
>> DOUBLE ARROW */
>>
>> In XFree86, it appears there was an error when they converted the
>> original table to
>> http://cvsweb.xfree86.org/cvsweb/xc/lib/X11/imKStoUCS.c?rev=1.1&content-type=text/vnd.viewcvs-markup
>> and the problem still shows up there (November 2000).
>
> The proposed fix:
>
> Peter Hutterer schrieb am 15.10.2008 08:02:
>>> When I have “implies”¹ in my xkbmap it produces not the expected
>>> >   U+21D2 RIGHTWARDS DOUBLE ARROW
>>> > as described in the comment of keysymdef.h but the symbol
>>> >   U+22A2 RIGHT TACK
>>> >
>>
>> Could this be the fix? Applies to libX11.
>> (I don't claim that I know what I'm doing here).
>>
>> diff --git a/src/xlibi18n/imKStoUCS.c b/src/xlibi18n/imKStoUCS.c
>> index 83c1483..4b4f628 100644
>> --- a/src/xlibi18n/imKStoUCS.c
>> +++ b/src/xlibi18n/imKStoUCS.c
>> @@ -120,7 +120,7 @@ static unsigned short const keysym_to_unicode_8a4_8fe[] = {
>>      0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, /* 0x08b0-0x08b7 */
>>      0x0000, 0x0000, 0x0000, 0x0000, 0x2264, 0x2260, 0x2265, 0x222b, /* 0x08b8-0x08bf */
>>      0x2234, 0x0000, 0x221e, 0x0000, 0x0000, 0x2207, 0x0000, 0x0000, /* 0x08c0-0x08c7 */
>> -    0x2245, 0x2246, 0x0000, 0x0000, 0x0000, 0x0000, 0x22a2, 0x0000, /* 0x08c8-0x08cf */
>> +    0x2245, 0x2246, 0x0000, 0x0000, 0x0000, 0x0000, 0x21d2, 0x0000, /* 0x08c8-0x08cf */
>>      0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x221a, 0x0000, /* 0x08d0-0x08d7 */
>>      0x0000, 0x0000, 0x2282, 0x2283, 0x2229, 0x222a, 0x2227, 0x2228, /* 0x08d8-0x08df */
>>      0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, /* 0x08e0-0x08e7 */
>>
>> Cheers,
>>   Peter
>
> hasn’t any discrepancies:
>
> Erik Streb del Toro schrieb am 17.11.2008 15:40:
>> James Cloos schrieb am 28.10.2008 00:21:
>>>>>>>> "Peter" == Peter Hutterer <peter.hutterer at who-t.net> writes:
>>>
>>> Peter> well, that's the issue with the whole thing (Erik and me
>>> Peter> discussed that a bit):
>>>
>>> Peter> keysymdef.h states that XK_implies is U+21D2 RIGHTWARDS DOUBLE
>>> Peter> ARROW.  in mathematics, this is the usual symbol for "implies".
>>> Peter> however, according to http://unicode.org/charts/PDF/U2200.pdf (p
>>> Peter> 207), "implies" is an alias for RIGHT TACK.
>>>
>>> I wonder whether ⊢ is used for implies in APL?
>>>
>>> Peter> As Erik pointed out, right tack does have its own symbol
>>> Peter> XK_righttack, whereas there's no other XK_... for the double
>>> Peter> right arrow.
>>>
>>> Sounds like a good reason to go with the comment.  As does Erik’s note
>>> that Gnome’s code follows the comment rather than the current imKStoUCS
>>> implementation.
>>>
>>> Has anyone audited imKStoUCS.c to see whether there are any other
>>> discrepancies?
>>>
>>> -JimC
>>
>> I’m still waiting for the solution of this little problem. I searched  
>> for discrepancies in imKStoUCS.c but couldn’t find any.
>>
>> So, will someone please commit the small bugfix? Or what are we waiting 
>> for?
>
> I don’t want to remind you again, because I want to forget about this  
> problem. ;-)
>
> Greetings,
> Erik