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 15 years and 322 days ago.

Previous Next


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