GNU bug report logs - #3745
23.0.95; emacs-23.0.95: unibyte-display-via-language-environment

Previous Next

Package: emacs;

Reported by: Jay Berkenbilt <ejb <at> ql.org>

Date: Fri, 3 Jul 2009 01:45:04 UTC

Severity: normal

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 3745 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: Jay Berkenbilt <ejb <at> ql.org>, 3745 <at> debbugs.gnu.org
Subject: Re: bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
Date: Fri, 03 Jul 2009 15:06:28 -0400
> Now `charset_unibyte' is always 0 (i.e. the same as
> `charset_ascii').  So, unibyte->multibyte conversion always
> results in an eight-bit multibyte character.

Looking through the code, I see that the variable `charset_unibyte' is
not initialized properly.  That's the only reason it's 0.  We have to
fix this for sure.

> To fix the above problem, I propose these changes for 23.1
> and the trunk.
>
> (1) Fix all codes accessing charset_unibyte
> (e.g. Funibyte_char_to_multibyte) not to refer to it.

Can we use charset_iso_8859_1 instead of charset_unibyte, or add a line
that says

  charset_unibyte
    = define_charset_internal (...);

in syms_of_charset?

> (2) Setup charset_unibyte correctly in Fset_charset_priority.
>
> (3) Fix x_produce_glyphs to do DECODE_CHAR (charset_unibyte,
>     it->c) instead of unibyte_char_to_multibyte (it->c).

Number 3 is not a trivial change.  IIUC, unibyte_char_to_multibyte is
very fast.  Changing it to use DECODE_CHAR may lead to a performance
hit.



This bug report was last modified 16 years and 9 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.