* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
@ 2009-07-03 1:39 Jay Berkenbilt
2009-07-03 6:42 ` Kenichi Handa
0 siblings, 1 reply; 10+ messages in thread
From: Jay Berkenbilt @ 2009-07-03 1:39 UTC (permalink / raw)
To: emacs-pretest-bug
I have this habit of editing binary files in emacs. I notice a change
in behavior in 23.0.95 (which is the first 23 pretest I've run) relative
to what I've seen in emacs 22. Specifically, I no longer see most
characters in unibyte mode. I'll be specific.
xrdb -load /dev/null
emacs-22 -q
M-x set-variable unibyte-display-via-language-environment RET t RET
M-x set-language-environment RET Latin-1 RET
M-x find-file-literally RET /bin/ls RET
In this case, I see ^x for characters between 0 and \037, the ASCII
character for \040-\177, \ooo for (unprintable) characters between \200
and \237, and the ISO-Latin-1 character for \240 through \377, as
expected.
With the same commands under emacs-23.0.95, I see ^x for \0 to \037, and
I see some normal 7-bit ASCII characters, but for other ASCII characters
and for everything \200 or above, I see various rectangles of various
widths. I can still see the buffer the way I want to by doing
C-x RET c iso-latin-1-unix RET C-x C-f /bin/ls
which is, I suppose, pretty much the same thing, but it seems like the
old behavior is right and the new behavior is probably a bug. Please
let me know if there's any other information I should supply.
----------------------------------------------------------------------
In GNU Emacs 23.0.95.1 (i686-pc-linux-gnu, GTK+ Version 2.16.1)
of 2009-06-25 on soup
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
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: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: Emacs-Lisp
Minor modes in effect:
which-function-mode: t
tooltip-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
column-number-mode: t
line-number-mode: t
Recent input:
C-h v s e t SPC l a n <tab> C-g C-h f s e t SPC a <backspace>
l <tab> a n <tab> e n <tab> <return> C-x b <return>
C-s s e t - l a n g C-s C-g C-g C-x 1 C-l C-v C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-z C-o C-n C-o C-o <tab> (
s e t - l a n g M-/ <backspace> SPC " L a t i n - 1
" ) C-x C-e C-x C-s C-x b l s <tab> <return> C-x C-v
<return> C-x b <return> C-x C-e C-x b <return> C-x
C-v <return> C-x k <return> C-x C-f / b i n l <backspace>
/ l s <tab> <return> M-x u n i <tab> b <tab> <return>
C-v C-v C-v C-v C-v M-> M-< C-n C-x u C-x u C-f C-f
C-z C-v C-f C-f C-f C-f C-f C-b C-z C-v C-x b <return>
C-s s e t - l a n C-g C-g C-x C-f ~ / e l <tab> q f
<tab> <M-backspace> <M-backspace> X r e <tab> f o n
<tab> <return> C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n M-f M-f M-f C-f C-SPC C-e M-w C-x C-x
M-w C-x C-f / b i n / l s <return> C-v C-v C-v C-v
C-v C-v C-v C-v C-v C-x k <return> C-h f u n i <tab>
b <tab> <return> C-x o C-e M-b <return> C-x m q <tab>
C-g C-x k <return> y e s <return> M-x r e p o r t SPC
e m SPC b SPC <return>
Recent messages:
U+0020
U+0028
Quit
Note: file is write protected
Mark set
Making completion list...
Type C-x 1 to delete the help window.
Note: file is write protected
Quit
Scanning for dabbrevs...100%
--
Jay Berkenbilt <ejb@ql.org>
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
2009-07-03 1:39 Jay Berkenbilt
@ 2009-07-03 6:42 ` Kenichi Handa
0 siblings, 0 replies; 10+ messages in thread
From: Kenichi Handa @ 2009-07-03 6:42 UTC (permalink / raw)
To: Jay Berkenbilt, 3745
In article <20090702213958.0458148346.qww314159@soup.q.qbilt.org>, Jay Berkenbilt <ejb@ql.org> writes:
> I have this habit of editing binary files in emacs. I notice a change
> in behavior in 23.0.95 (which is the first 23 pretest I've run) relative
> to what I've seen in emacs 22. Specifically, I no longer see most
> characters in unibyte mode. I'll be specific.
> xrdb -load /dev/null
> emacs-22 -q
> M-x set-variable unibyte-display-via-language-environment RET t RET
> M-x set-language-environment RET Latin-1 RET
> M-x find-file-literally RET /bin/ls RET
> In this case, I see ^x for characters between 0 and \037, the ASCII
> character for \040-\177, \ooo for (unprintable) characters between \200
> and \237, and the ISO-Latin-1 character for \240 through \377, as
> expected.
I confirmed the bug. The problem is that
unibyte_char_to_multibyte now always returns an eight-bit
multibyte-character.
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.
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.
(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).
Those changes are surely very safe.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
@ 2009-07-03 14:26 Chong Yidong
2009-07-06 0:51 ` Kenichi Handa
0 siblings, 1 reply; 10+ messages in thread
From: Chong Yidong @ 2009-07-03 14:26 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 3745
> Now `charset_unibyte' is always 0 (i.e. the same as `charset_ascii').
Is this variable obsolete, then?
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
@ 2009-07-03 19:06 Chong Yidong
0 siblings, 0 replies; 10+ messages in thread
From: Chong Yidong @ 2009-07-03 19:06 UTC (permalink / raw)
To: Kenichi Handa; +Cc: Jay Berkenbilt, 3745
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
2009-07-03 14:26 bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment Chong Yidong
@ 2009-07-06 0:51 ` Kenichi Handa
2009-07-06 6:50 ` Kenichi Handa
0 siblings, 1 reply; 10+ messages in thread
From: Kenichi Handa @ 2009-07-06 0:51 UTC (permalink / raw)
To: Chong Yidong; +Cc: 3745
In article <87bpo13ks8.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:
> > Now `charset_unibyte' is always 0 (i.e. the same as `charset_ascii').
> Is this variable obsolete, then?
Yes, at the moment. But, I'd like to use it for
unibyte-display-via-language-environment.
In article <87y6r560y3.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:
> > 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.
Yes.
> > 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?
No. Stefan's change was to make unibyte-char-to-multibyte
(and unibyte_char_to_multibyte) always returning an 8-bit
char for an 8-bit byte. To do that, charset_unibyte must be
the same as charset_ascii, but, first of all, we don't have
to use charset_unibyte in such an operation. We can simply
use BYTE8_TO_CHAR.
> > (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.
But, using unibyte_char_to_multibyte here is a clear bug.
If the overhead by DECODE_CHAR is untolerable (I don't
believe it), we can do this:
(1) modify unibyte_char_to_multibyte to use BYTE8_TO_CHAR
instead of the table unibyte_to_multibyte_table.
(2) Setup unibyte_to_multibyte_table for unibyte_charset.
(3) Just lookup that table in x_produce_glyphs.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
2009-07-06 0:51 ` Kenichi Handa
@ 2009-07-06 6:50 ` Kenichi Handa
2009-07-06 14:03 ` Chong Yidong
2009-07-07 12:33 ` Andreas Schwab
0 siblings, 2 replies; 10+ messages in thread
From: Kenichi Handa @ 2009-07-06 6:50 UTC (permalink / raw)
To: 3745; +Cc: cyd, 3745
In article <tl74otqk501.fsf@m17n.org>, Kenichi Handa <handa@m17n.org> writes:
> But, using unibyte_char_to_multibyte here is a clear bug.
> If the overhead by DECODE_CHAR is untolerable (I don't
> believe it), we can do this:
> (1) modify unibyte_char_to_multibyte to use BYTE8_TO_CHAR
> instead of the table unibyte_to_multibyte_table.
> (2) Setup unibyte_to_multibyte_table for unibyte_charset.
> (3) Just lookup that table in x_produce_glyphs.
To minimize the changes, I made the attached patch. It
doesn't touch unibyte_to_multibyte_table, but introduced
charset_unibyte_decoder[128]. I confirmed it didn't make
the display code slow.
---
Kenichi Handa
handa@m17n.org
Index: character.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/character.c,v
retrieving revision 1.24
diff -u -r1.24 character.c
--- character.c 5 Feb 2009 08:46:52 -0000 1.24
+++ character.c 6 Jul 2009 06:42:31 -0000
@@ -90,9 +90,9 @@
/* Mapping table from unibyte chars to multibyte chars. */
int unibyte_to_multibyte_table[256];
-/* Nth element is 1 iff unibyte char N can be mapped to a multibyte
- char. */
-char unibyte_has_multibyte_table[256];
+/* Decoding table for 8-bit byte codes of the charset charset_unibyte.
+ Nth element is for the code (N-0x80). */
+int charset_unibyte_decoder[128];
\f
@@ -270,9 +270,8 @@
return c;
}
-/* Convert the multibyte character C to unibyte 8-bit character based
- on the current value of charset_unibyte. If dimension of
- charset_unibyte is more than one, return (C & 0xFF).
+/* Convert ASCII or 8-bit character C to unibyte. If C is none of
+ them, return (C & 0xFF).
The argument REV_TBL is now ignored. It will be removed in the
future. */
@@ -282,14 +281,11 @@
int c;
Lisp_Object rev_tbl;
{
- struct charset *charset;
- unsigned c1;
-
+ if (c < 0x80)
+ return c;
if (CHAR_BYTE8_P (c))
return CHAR_TO_BYTE8 (c);
- charset = CHARSET_FROM_ID (charset_unibyte);
- c1 = ENCODE_CHAR (charset, c);
- return ((c1 != CHARSET_INVALID_CODE (charset)) ? c1 : c & 0xFF);
+ return (c & 0xFF);
}
/* Like multibyte_char_to_unibyte, but return -1 if C is not supported
@@ -302,11 +298,11 @@
struct charset *charset;
unsigned c1;
+ if (c < 0x80)
+ return c;
if (CHAR_BYTE8_P (c))
return CHAR_TO_BYTE8 (c);
- charset = CHARSET_FROM_ID (charset_unibyte);
- c1 = ENCODE_CHAR (charset, c);
- return ((c1 != CHARSET_INVALID_CODE (charset)) ? c1 : -1);
+ return -1;
}
DEFUN ("characterp", Fcharacterp, Scharacterp, 1, 2, 0,
@@ -337,10 +333,8 @@
c = XFASTINT (ch);
if (c >= 0400)
error ("Invalid unibyte character: %d", c);
- charset = CHARSET_FROM_ID (charset_unibyte);
- c = DECODE_CHAR (charset, c);
- if (c < 0)
- c = BYTE8_TO_CHAR (XFASTINT (ch));
+ if (c >= 0x80)
+ c = BYTE8_TO_CHAR (c);
return make_number (c);
}
Index: character.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/character.h,v
retrieving revision 1.15
diff -u -r1.15 character.h
--- character.h 8 Jan 2009 03:15:27 -0000 1.15
+++ character.h 6 Jul 2009 06:42:31 -0000
@@ -87,11 +87,15 @@
#define unibyte_char_to_multibyte(c) \
((c) < 256 ? unibyte_to_multibyte_table[(c)] : (c))
-/* Nth element is 1 iff unibyte char N can be mapped to a multibyte
- char. */
-extern char unibyte_has_multibyte_table[256];
-
-#define UNIBYTE_CHAR_HAS_MULTIBYTE_P(c) (unibyte_has_multibyte_table[(c)])
+/* Decoding table for 8-bit byte codes of the charset charset_unibyte.
+ Nth element is for the code (N-0x80). */
+extern int charset_unibyte_decoder[128];
+
+/* Return a character correspoinding to the code BYTE of
+ charset_unibyte. BYTE must be a byte; i.e. less than 0x100. If
+ BYTE is not a valid code of charset_unibyte, return -1. */
+#define DECODE_UNIBYTE(BYTE) \
+ ((BYTE) < 0x80 ? (int) (BYTE) : charset_unibyte_decoder[(BYTE) - 0x80])
/* If C is not ASCII, make it unibyte. */
#define MAKE_CHAR_UNIBYTE(c) \
Index: charset.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/charset.c,v
retrieving revision 1.179
diff -u -r1.179 charset.c
--- charset.c 9 Jun 2009 02:53:07 -0000 1.179
+++ charset.c 6 Jul 2009 06:42:32 -0000
@@ -2260,6 +2260,7 @@
Vcharset_ordered_list = Fnconc (2, arglist);
charset_ordered_list_tick++;
+ charset_unibyte = -1;
for (old_list = Vcharset_ordered_list, list_2022 = list_emacs_mule = Qnil;
CONSP (old_list); old_list = XCDR (old_list))
{
@@ -2267,9 +2268,25 @@
list_2022 = Fcons (XCAR (old_list), list_2022);
if (! NILP (Fmemq (XCAR (old_list), Vemacs_mule_charset_list)))
list_emacs_mule = Fcons (XCAR (old_list), list_emacs_mule);
+ if (charset_unibyte < 0)
+ {
+ struct charset *charset = CHARSET_FROM_ID (XINT (XCAR (old_list)));
+
+ if (CHARSET_DIMENSION (charset) == 1
+ && CHARSET_ASCII_COMPATIBLE_P (charset)
+ && CHARSET_MAX_CHAR (charset) >= 0x80)
+ charset_unibyte = CHARSET_ID (charset);
+ }
}
Viso_2022_charset_list = Fnreverse (list_2022);
Vemacs_mule_charset_list = Fnreverse (list_emacs_mule);
+ if (charset_unibyte < 0)
+ charset_unibyte = charset_iso_8859_1;
+ {
+ struct charset *charset = CHARSET_FROM_ID (charset_unibyte);
+ for (i = 128; i < 256; i++)
+ charset_unibyte_decoder[i - 128] = DECODE_CHAR (charset, i);
+ }
return Qnil;
}
@@ -2328,6 +2345,10 @@
unibyte_to_multibyte_table[i] = i;
for (; i < 256; i++)
unibyte_to_multibyte_table[i] = BYTE8_TO_CHAR (i);
+ for (i = 0; i < 32; i++)
+ charset_unibyte_decoder[i] = -1;
+ for (; i < 128; i++)
+ charset_unibyte_decoder[i] = 128 + i;
}
#ifdef emacs
@@ -2429,6 +2450,7 @@
= define_charset_internal (Qeight_bit, 1, "\x80\xFF\x00\x00\x00\x00",
128, 255, -1, 0, -1, 0, 1,
MAX_5_BYTE_CHAR + 1);
+ charset_unibyte = charset_iso_8859_1;
}
#endif /* emacs */
Index: xdisp.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/xdisp.c,v
retrieving revision 1.1288
diff -u -r1.1288 xdisp.c
--- xdisp.c 18 Jun 2009 09:49:07 -0000 1.1288
+++ xdisp.c 6 Jul 2009 06:42:34 -0000
@@ -5743,7 +5743,7 @@
|| it->c == 0xAD /* SOFT HYPHEN */)))
: (it->c >= 127
&& (! unibyte_display_via_language_environment
- || (UNIBYTE_CHAR_HAS_MULTIBYTE_P (it->c)))))))
+ || (DECODE_UNIBYTE (it->c) <= 0xA0))))))
{
/* IT->c is a control character which must be displayed
either as '\003' or as `^C' where the '\\' and '^'
@@ -21196,9 +21196,8 @@
{
if (SINGLE_BYTE_CHAR_P (it->c)
&& unibyte_display_via_language_environment)
- it->char_to_display = unibyte_char_to_multibyte (it->c);
- if (! SINGLE_BYTE_CHAR_P (it->char_to_display))
{
+ it->char_to_display = DECODE_UNIBYTE (it->c);
it->multibyte_p = 1;
it->face_id = FACE_FOR_CHAR (it->f, face, it->char_to_display,
-1, Qnil);
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
2009-07-06 6:50 ` Kenichi Handa
@ 2009-07-06 14:03 ` Chong Yidong
2009-07-07 6:28 ` Kenichi Handa
2009-07-07 12:33 ` Andreas Schwab
1 sibling, 1 reply; 10+ messages in thread
From: Chong Yidong @ 2009-07-06 14:03 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 3745
Kenichi Handa <handa@m17n.org> writes:
> To minimize the changes, I made the attached patch. It
> doesn't touch unibyte_to_multibyte_table, but introduced
> charset_unibyte_decoder[128]. I confirmed it didn't make
> the display code slow.
> @@ -302,11 +298,11 @@
> struct charset *charset;
> unsigned c1;
>
> + if (c < 0x80)
> + return c;
> if (CHAR_BYTE8_P (c))
> return CHAR_TO_BYTE8 (c);
You should also delete the unused `charset' and `c1' variables in this
block.
Other than that, these changes look good. Thanks very much for making
this patch, and please install on the branch ASAP.
For the trunk, I agree that we should try using use DECODE_CHAR in
x_produce_glyphs.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
2009-07-06 14:03 ` Chong Yidong
@ 2009-07-07 6:28 ` Kenichi Handa
0 siblings, 0 replies; 10+ messages in thread
From: Kenichi Handa @ 2009-07-07 6:28 UTC (permalink / raw)
To: Chong Yidong; +Cc: 3745
In article <87my7h6h81.fsf@stupidchicken.com>, Chong Yidong <cyd@stupidchicken.com> writes:
> Kenichi Handa <handa@m17n.org> writes:
> > To minimize the changes, I made the attached patch. It
> > doesn't touch unibyte_to_multibyte_table, but introduced
> > charset_unibyte_decoder[128]. I confirmed it didn't make
> > the display code slow.
> > @@ -302,11 +298,11 @@
> > struct charset *charset;
> > unsigned c1;
> >
> > + if (c < 0x80)
> > + return c;
> > if (CHAR_BYTE8_P (c))
> > return CHAR_TO_BYTE8 (c);
> You should also delete the unused `charset' and `c1' variables in this
> block.
Ah, yes.
> Other than that, these changes look good. Thanks very much for making
> this patch, and please install on the branch ASAP.
> For the trunk, I agree that we should try using use DECODE_CHAR in
> x_produce_glyphs.
Ok, done. I also installed this change of
reset-language-environment for completion.
--- mule-cmds.el 8 Apr 2009 18:03:17 -0000 1.360
+++ mule-cmds.el 7 Jul 2009 05:59:18 -0000 1.360.2.1
@@ -1794,6 +1794,11 @@
(coding-system-error 'iso-latin-1))))
(setq default-process-coding-system
(cons output-coding input-coding)))
+ ;; Put the highest priority to the charset iso-8859-1 to prefer the
+ ;; registry iso8859-1 over iso8859-2 in font selection. It also
+ ;; makes unibyte-display-via-language-environment to use iso-8859-1
+ ;; as the unibyte charset.
+ (set-charset-priority 'iso-8859-1)
;; Don't alter the terminal and keyboard coding systems here.
;; The terminal still supports the same coding system
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
2009-07-06 6:50 ` Kenichi Handa
2009-07-06 14:03 ` Chong Yidong
@ 2009-07-07 12:33 ` Andreas Schwab
2009-07-07 12:45 ` Kenichi Handa
1 sibling, 1 reply; 10+ messages in thread
From: Andreas Schwab @ 2009-07-07 12:33 UTC (permalink / raw)
To: Kenichi Handa; +Cc: cyd, 3745
Kenichi Handa <handa@m17n.org> writes:
> +/* Decoding table for 8-bit byte codes of the charset charset_unibyte.
> + Nth element is for the code (N-0x80). */
You probably mean (N+0x80).
> +int charset_unibyte_decoder[128];
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment
2009-07-07 12:33 ` Andreas Schwab
@ 2009-07-07 12:45 ` Kenichi Handa
0 siblings, 0 replies; 10+ messages in thread
From: Kenichi Handa @ 2009-07-07 12:45 UTC (permalink / raw)
To: Andreas Schwab; +Cc: cyd, 3745
In article <m3bpnwisff.fsf@hase.home>, Andreas Schwab <schwab@linux-m68k.org> writes:
> Kenichi Handa <handa@m17n.org> writes:
> > +/* Decoding table for 8-bit byte codes of the charset charset_unibyte.
> > + Nth element is for the code (N-0x80). */
> You probably mean (N+0x80).
Yes! Just fixed, thank you.
---
Kenichi Handa
handa@m17n.org
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-07-07 12:45 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-07-03 14:26 bug#3745: 23.0.95; emacs-23.0.95: unibyte-display-via-language-environment Chong Yidong
2009-07-06 0:51 ` Kenichi Handa
2009-07-06 6:50 ` Kenichi Handa
2009-07-06 14:03 ` Chong Yidong
2009-07-07 6:28 ` Kenichi Handa
2009-07-07 12:33 ` Andreas Schwab
2009-07-07 12:45 ` Kenichi Handa
-- strict thread matches above, loose matches on Subject: below --
2009-07-03 19:06 Chong Yidong
2009-07-03 1:39 Jay Berkenbilt
2009-07-03 6:42 ` Kenichi Handa
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.