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

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

Re: [PATCH] Unicode Lisp reader escapes.


From: Eli Zaretskii
Subject: Re: [PATCH] Unicode Lisp reader escapes.
Date: Fri, 09 Jun 2006 21:30:08 +0300

> From: Aidan Kehoe <address@hidden>
> Date: Sat, 3 Jun 2006 20:32:31 +0200
> 
> Jonas Jacobson just sent me confirmation that my once again signed
> assignments have been received, together with PDF copies of same. Given
> that, here is my final version of the patch I proposed in my first mail;
> differences from that version are an entry in the NEWS file, some prose
> style changes in the manual, and a GCPRO to protect readcharfun in lread.c.

Thanks.  I installed these (with some minor stylistic changes in the
documentation patches).  For the future, please note that we leave two
spaces after each period that ends a sentence, including the last
sentence in a C comment.

> address@hidden unicode character escape
> +  Emacs provides a syntax for specifying characters by their Unicode code
> +points.  @code{?\uABCD} represents a character that maps to the code
> +point @samp{U+ABCD} in Unicode-based representations (UTF-8 text files,
> +Unicode-oriented fonts, etc.).  There is a slightly different syntax for
> +specifying characters with code points above @code{#xFFFF};
> address@hidden represents an Emacs character that maps to the code
> +point @samp{U+ABCDEF} in Unicode-based representations, if such an Emacs
> +character exists.

The last sentence hints that something special happens if the
specified Unicode code point does not correspond to any valid Emacs
character, but it leaves the specifics untold.  I think we should
document that explicitly.  I tried to understand what the code does in
that case (decode-char returns nil), but all I see is this code
fragment with an unhelpful comment:

        if (EQ(Qnil, lisp_char))
          {
            /* This is ugly and horrible and trashes the user's data. */
            XSETFASTINT (i, MAKE_CHAR (charset_katakana_jisx0201, 
                                       34 + 128, 46 + 128));
            return i;
          }

What is this special Katakana character, and why are we producing it?
Is it to trigger an "Invalid character" message, or is something else
going on here?




reply via email to

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