Re: [Torsten Bronger] Re: 23.0.60; Unicode display problems

Re: [Torsten Bronger] Re: 23.0.60; Unicode display problems

[Kenichi Handa]

In article <871w022tmy.fsf@cyd.mit.edu>, Chong Yidong <cyd@stupidchicken.com> writes:

> Chong Yidong writes:

> > Do you still see a problem with the latest CVS code,
> with Kenichi > Handa's changes?

> Everything works now like before the change that broke it
> for me.

> But I saw another regression in that area, maybe
> introduced by related changes: Combining diacritical marks
> may vanish from display.  If I have a letter followed by a
> dot accent, for example, I don't see the dot; neither on
> the letter, nor directly after it.

It seems that there's a bug in the new code for composing
diacritical marks.  As Juanma mailed, currently C-u C-x =
doesn't report how charaters are composed.  I'm now working
on fixing it.  When it is done, we can see what is wrong
easily.  Please wait for a while.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] Re: 23.0.60; Unicode display problems

[Miles Bader]

Kenichi Handa <handa@m17n.org> writes:
> It seems that there's a bug in the new code for composing
> diacritical marks.  As Juanma mailed, currently C-u C-x =
> doesn't report how charaters are composed.  I'm now working
> on fixing it.  When it is done, we can see what is wrong
> easily.  Please wait for a while.

Are there composed characters in HELLO?

-Miles

-- 
[|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that
            will  make every christian in the world foamm at the mouth?
[iddt]      nurg, that's the goal

Re: [Torsten Bronger] Re: 23.0.60; Unicode display problems

[Jason Rumney]

Miles Bader wrote:
> Are there composed characters in HELLO?
>   
Thai and the various Indian scripts are composed.

Re: [Torsten Bronger] Re: 23.0.60; Unicode display problems

[Kenichi Handa]

In article <E1KanUY-0007G9-KM@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:

> It seems that there's a bug in the new code for composing
> diacritical marks.  As Juanma mailed, currently C-u C-x =
> doesn't report how charaters are composed.  I'm now working
> on fixing it.  When it is done, we can see what is wrong
> easily.  Please wait for a while.

I've just installed a fix.  Please insert an alphabet
followed by a disappearing combining diacritical mark in a
buffer, move cursor to the alphabet, and type C-u C-x =.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> Kenichi Handa <handa@m17n.org> writes:
>
>> It seems that there's a bug in the new code for composing
>> diacritical marks.  As Juanma mailed, currently C-u C-x = doesn't
>> report how charaters are composed.  I'm now working on fixing it.
>> When it is done, we can see what is wrong easily.  Please wait
>> for a while.
>
> I've just installed a fix.  Please insert an alphabet followed by
> a disappearing combining diacritical mark in a buffer, move cursor
> to the alphabet, and type C-u C-x =.

It says

        character: x (120, #o170, #x78)
preferred charset: ascii (ASCII (ISO646 IRV))
       code point: 0x78
           syntax: w 	which means: word
         category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0]) l:Latin r:Japanese roman
      buffer code: #x78
        file code: #x78 (encoded by coding system utf-8-unix)
          display: composed to form "ẍ̇" (see below)

Composed with the following character(s) "̈̇" using this font:
  xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 2 120 91 10 0 10 10 0 nil]
  [0 2 776 644 10 2 8 14 -12 [-10 -4 0]]
  [0 2 775 643 10 4 6 14 -12 [-10 -4 0]]

Character code properties: customize what to show
  name: LATIN SMALL LETTER X
  general-category: Ll (Letter, Lowercase)


The current CVS head still doesn't work in this respect.  I can't
move point before the accented character -- the cursor is really
stuck.  Besides, longline-mode still stops working beyond the first
combining diacritical mark.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <87myilc8tg.fsf@physik.rwth-aachen.de>, Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

>>> It seems that there's a bug in the new code for composing
>>> diacritical marks.  As Juanma mailed, currently C-u C-x = doesn't
>>> report how charaters are composed.  I'm now working on fixing it.
>>> When it is done, we can see what is wrong easily.  Please wait
>>> for a while.
> >
> > I've just installed a fix.  Please insert an alphabet followed by
> > a disappearing combining diacritical mark in a buffer, move cursor
> > to the alphabet, and type C-u C-x =.

> It says
[...]
>   xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1
> by these glyphs:
>   [0 2 120 91 10 0 10 10 0 nil]
>   [0 2 776 644 10 2 8 14 -12 [-10 -4 0]]
>   [0 2 775 643 10 4 6 14 -12 [-10 -4 0]]

Please try again with the latest code.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <E1Kcszs-0004UZ-4p@etlken.m17n.org>, Kenichi Handa <handa@m17n.org> writes:

> > It says
> [...]
> >   xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1
> > by these glyphs:
> >   [0 2 120 91 10 0 10 10 0 nil]
> >   [0 2 776 644 10 2 8 14 -12 [-10 -4 0]]
> >   [0 2 775 643 10 4 6 14 -12 [-10 -4 0]]

> Please try again with the latest code.

By the way, do you compile Emacs with m17n-lib?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> [...]
>
>>> I've just installed a fix.  Please insert an alphabet followed
>>> by a disappearing combining diacritical mark in a buffer, move
>>> cursor to the alphabet, and type C-u C-x =.
>
>> It says
>> [...]
>> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1
>> by these glyphs:
>>   [0 2 120 91 10 0 10 10 0 nil]
>>   [0 2 776 644 10 2 8 14 -12 [-10 -4 0]]
>>   [0 2 775 643 10 4 6 14 -12 [-10 -4 0]]
>
> Please try again with the latest code.

        character: x (120, #o170, #x78)
preferred charset: ascii (ASCII (ISO646 IRV))
       code point: 0x78
           syntax: w 	which means: word
         category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0]) l:Latin r:Japanese roman
      buffer code: #x78
        file code: #x78 (encoded by coding system utf-8-unix)
          display: composed to form "ẍ̇" (see below)

Composed with the following character(s) "̈̇" using this font:
  xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 2 120 91 8 0 8 7 0 nil]
  [0 2 776 644 8 2 6 10 -8 [-8 -2 0]]
  [0 2 775 643 8 3 5 10 -8 [-8 -2 0]]

Character code properties: customize what to show
  name: LATIN SMALL LETTER X
  general-category: Ll (Letter, Lowercase)

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> In article <E1Kcszs-0004UZ-4p@etlken.m17n.org>, Kenichi Handa <handa@m17n.org>
> writes:
>
>>> It says
>> [...]
>>> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1
>>> by these glyphs:
>>>   [0 2 120 91 10 0 10 10 0 nil]
>>>   [0 2 776 644 10 2 8 14 -12 [-10 -4 0]]
>>>   [0 2 775 643 10 4 6 14 -12 [-10 -4 0]]
>
>> Please try again with the latest code.
>
> By the way, do you compile Emacs with m17n-lib?

No.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <87sks9eqxt.fsf@physik.rwth-aachen.de>, Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> > By the way, do you compile Emacs with m17n-lib?

> No.

Ah, I see.  Without m17n-lib (and libotf), Emacs can't
utilize OpenType table in the font.  In such a case, Emacs
artificially adjusts the placement of combining characters.
I've just fixed a code for doing that.  So, please try again
with the latest code.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> In article <87sks9eqxt.fsf@physik.rwth-aachen.de>, Torsten Bronger
> <bronger@physik.rwth-aachen.de> writes:
>
>>> By the way, do you compile Emacs with m17n-lib?
>
>> No.
>
> Ah, I see.  Without m17n-lib (and libotf), Emacs can't
> utilize OpenType table in the font.  In such a case, Emacs
> artificially adjusts the placement of combining characters.
> I've just fixed a code for doing that.  So, please try again
> with the latest code.

The accents look very nice now, even multiple diacritics on the same
letter are stacked correctly.  However, I still can't pass the letter
with the cursor.  And, when I want to view this email with Gnus, it
says "apply: Args out of range: 1399, 1399".

        character: x (120, #o170, #x78)
preferred charset: ascii (ASCII (ISO646 IRV))
       code point: 0x78
           syntax: w 	which means: word
         category: a:ASCII graphic characters 32-126 (ISO646 IRV:1983[4/0]) l:Latin r:Japanese roman
      buffer code: #x78
        file code: #x78 (encoded by coding system utf-8-unix)
          display: composed to form "ẍ" (see below)

Composed with the following character(s) "̈" using this font:
  xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1
by these glyphs:
  [0 1 120 91 8 0 8 7 0 nil]
  [0 1 776 644 8 2 6 10 -8 [-8 0 0]]

Character code properties: customize what to show
  name: LATIN SMALL LETTER X
  general-category: Ll (Letter, Lowercase)

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> In article <87sks9eqxt.fsf@physik.rwth-aachen.de>, Torsten Bronger
> <bronger@physik.rwth-aachen.de> writes:
>
>>> By the way, do you compile Emacs with m17n-lib?
>
>> No.
>
> Ah, I see.  Without m17n-lib (and libotf),

I installed the -dev and -bin packages for Ubuntu of both libraries,
and now Emacs quits with a seg fault when I move the cursor over an
accented character.  However, I can't tell whether the libraries are
properly installed because I don't know how to test it.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <87prncctrp.fsf@physik.rwth-aachen.de>, Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> I installed the -dev and -bin packages for Ubuntu of both libraries,
> and now Emacs quits with a seg fault when I move the cursor over an
> accented character.  However, I can't tell whether the libraries are
> properly installed because I don't know how to test it.

Which version of m17n-flt/libotf are they?  Perhaps:

% pkg-config --modversion m17n-flt
% pkg-config --modversion libotf

will tell it.

Anyway, please run Emacs under gdb and find at which point
it segfaults.  It seems that composition_adjust_point still
has a bug.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Juanma Barranquero]

On Wed, Sep 10, 2008 at 10:11, Kenichi Handa <handa@m17n.org> wrote:

> Anyway, please run Emacs under gdb and find at which point
> it segfaults.  It seems that composition_adjust_point still
> has a bug.

I'm not the OP, but I can reproduce the crash. This is just C-h H and
moving the cursor around.

  Juanma


Program received signal SIGSEGV, Segmentation fault.
0x0119a011 in composition_update_it (cmp_it=0x82eea8, charpos=1697,
bytepos=2496, string=47732737) at composite.c:1152
1152                if ((c = COMPOSITION_GLYPH (cmp, i)) != '\t')
(gdb) bt
#0  0x0119a011 in composition_update_it (cmp_it=0x82eea8,
charpos=1697, bytepos=2496, string=47732737)
    at composite.c:1152
#1  0x0103295d in next_element_from_composition (it=0x82eafc) at xdisp.c:6573
#2  0x01032a78 in next_element_from_buffer (it=0x82eafc) at xdisp.c:6458
#3  0x0102fe20 in get_next_display_element (it=0x82eafc) at xdisp.c:5654
#4  0x01030ff8 in move_it_in_display_line_to (it=0x82eafc,
to_charpos=1728, to_x=-1, op=MOVE_TO_POS) at xdisp.c:6695
#5  0x01032244 in move_it_to (it=0x82eafc, to_charpos=1728, to_x=-1,
to_y=-1, to_vpos=-1, op=8) at xdisp.c:7190
#6  0x010355e9 in move_it_by_lines (it=0x82efc8, dvpos=-1, need_y_p=0)
at xdisp.c:7540
#7  0x011749de in Fvertical_motion (lines=<value optimized out>,
window=47732737) at indent.c:2103
#8  0x01019d4e in Ffuncall (nargs=2, args=0x82f520) at eval.c:3047
#9  0x01145ea4 in Fbyte_code (bytestr=19424267, vector=19424372,
maxdepth=<value optimized out>) at bytecode.c:678
#10 0x0101c236 in funcall_lambda (fun=19424220, nargs=2,
arg_vector=0x82f654) at eval.c:3231
#11 0x0101997c in Ffuncall (nargs=3, args=0x82f650) at eval.c:3090
#12 0x01145ea4 in Fbyte_code (bytestr=19424059, vector=19424148,
maxdepth=<value optimized out>) at bytecode.c:678
#13 0x0101c236 in funcall_lambda (fun=19423996, nargs=4,
arg_vector=0x82f784) at eval.c:3231
#14 0x0101997c in Ffuncall (nargs=5, args=0x82f780) at eval.c:3090
#15 0x01145ea4 in Fbyte_code (bytestr=19423187, vector=19423236,
maxdepth=<value optimized out>) at bytecode.c:678
#16 0x0101bbd4 in Feval (form=19423173) at eval.c:2381
#17 0x0101cab3 in internal_lisp_condition_case (var=47732737,
bodyform=19423173, handlers=19423269) at eval.c:1456
#18 0x01146735 in Fbyte_code (bytestr=19423075, vector=19423132,
maxdepth=<value optimized out>) at bytecode.c:868
#19 0x0101c236 in funcall_lambda (fun=19423020, nargs=2,
arg_vector=0x82fac4) at eval.c:3231
#20 0x0101997c in Ffuncall (nargs=3, args=0x82fac0) at eval.c:3090
#21 0x0114905d in Fcall_interactively (function=47819689,
record_flag=47732737, keys=47766276) at callint.c:857
#22 0x01019d86 in Ffuncall (nargs=4, args=0x82fc88) at eval.c:3050
#23 0x0101a008 in call3 (fn=47924321, arg1=47819689, arg2=47732737,
arg3=47732737) at eval.c:2870
#24 0x0109302c in command_loop_1 () at keyboard.c:1880
#25 0x010190c6 in internal_condition_case (bfun=0x1092a53
<command_loop_1>, handlers=47796489,
    hfun=0x1089cd6 <cmd_error>) at eval.c:1511
#26 0x0108917b in command_loop_2 () at keyboard.c:1338
#27 0x01019170 in internal_catch (tag=47792561, func=0x1089158
<command_loop_2>, arg=47732737) at eval.c:1247
#28 0x01089b1b in command_loop () at keyboard.c:1317
#29 0x01089e6f in recursive_edit_1 () at keyboard.c:942
#30 0x01089fda in Frecursive_edit () at keyboard.c:1004
#31 0x01002c41 in main (argc=2, argv=0xa941e0) at emacs.c:1693

Lisp Backtrace:
"vertical-motion" (0x82f524)
"line-move-visual" (0x82f654)
"line-move" (0x82f784)
"byte-code" (0x82f830)
"previous-line" (0x82fac4)
"call-interactively" (0x82fc8c)
(gdb)

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <f7ccd24b0809100120r7e6e7f46l66f8e34a06ef0744@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes:

> On Wed, Sep 10, 2008 at 10:11, Kenichi Handa <handa@m17n.org> wrote:
> > Anyway, please run Emacs under gdb and find at which point
> > it segfaults.  It seems that composition_adjust_point still
> > has a bug.

> I'm not the OP, but I can reproduce the crash. This is just C-h H and
> moving the cursor around.

>   Juanma


> Program received signal SIGSEGV, Segmentation fault.
> 0x0119a011 in composition_update_it (cmp_it=0x82eea8, charpos=1697,
> bytepos=2496, string=47732737) at composite.c:1152
> 1152                if ((c = COMPOSITION_GLYPH (cmp, i)) != '\t')
> (gdb) bt
> #0  0x0119a011 in composition_update_it (cmp_it=0x82eea8,
> charpos=1697, bytepos=2496, string=47732737)
>     at composite.c:1152

Thank you for the info.  What is the value of *cmp_it at
that time?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Juanma Barranquero]

On Wed, Sep 10, 2008 at 12:21, Kenichi Handa <handa@m17n.org> wrote:

> What is the value of *cmp_it at that time?

I've got two crashes, almost identical to the one above but they crash
at composite.c:1144 instead:

Program received signal SIGSEGV, Segmentation fault.
0x01199f9c in composition_update_it (cmp_it=0x82eea8, charpos=1432,
bytepos=2086, string=47732737) at composite.c:1144
1144          struct composition *cmp = composition_table[cmp_it->id];
(gdb) bt
#0  0x01199f9c in composition_update_it (cmp_it=0x82eea8,
charpos=1432, bytepos=2086, string=47732737)
    at composite.c:1144
#1  0x0103295d in next_element_from_composition (it=0x82eafc) at xdisp.c:6573
#2  0x01032a78 in next_element_from_buffer (it=0x82eafc) at xdisp.c:6458
#3  0x0102fe20 in get_next_display_element (it=0x82eafc) at xdisp.c:5654
[etc]

(gdb) p *cmp_it
$2 = {
  stop_pos = 1485,
  id = 5,
  ch = -2,
  lookback = 0,
  nglyphs = 1,
  nchars = 1,
  nbytes = 3,
  from = 0,
  to = 1,
  width = 1
}


Program received signal SIGSEGV, Segmentation fault.
0x01199f9c in composition_update_it (cmp_it=0x82eea8, charpos=1942,
bytepos=2818, string=47732737) at composite.c:1144
1144          struct composition *cmp = composition_table[cmp_it->id];
(gdb) bt
#0  0x01199f9c in composition_update_it (cmp_it=0x82eea8,
charpos=1942, bytepos=2818, string=47732737)
    at composite.c:1144
#1  0x0103295d in next_element_from_composition (it=0x82eafc) at xdisp.c:6573
#2  0x01032a78 in next_element_from_buffer (it=0x82eafc) at xdisp.c:6458
#3  0x0102fe20 in get_next_display_element (it=0x82eafc) at xdisp.c:5654
[etc]

(gdb) p *cmp_it
$2 = {
  stop_pos = 1982,
  id = 19,
  ch = -2,
  lookback = 0,
  nglyphs = 1,
  nchars = 2,
  nbytes = 6,
  from = 0,
  to = 1,
  width = 1
}

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Juanma Barranquero]

The crashes before were with an optimized build, but a non-optimized
one fails in the same fashion:

Program received signal SIGSEGV, Segmentation fault.
0x012a8e9f in composition_update_it (cmp_it=0x82e3c0, charpos=1697,
bytepos=2496, string=48666625) at composite.c:1144
1144          struct composition *cmp = composition_table[cmp_it->id];
(gdb) bt
#0  0x012a8e9f in composition_update_it (cmp_it=0x82e3c0,
charpos=1697, bytepos=2496, string=48666625)
    at composite.c:1144
#1  0x01065e57 in next_element_from_composition (it=0x82e014) at xdisp.c:6573
#2  0x01065977 in next_element_from_buffer (it=0x82e014) at xdisp.c:6458
#3  0x01062d3c in get_next_display_element (it=0x82e014) at xdisp.c:5654
[etc]

(gdb) p *cmp_it
$1 = {
  stop_pos = 1728,
  id = 13,
  ch = -2,
  lookback = 0,
  nglyphs = 6,
  nchars = 2,
  nbytes = 6,
  from = 0,
  to = 2,
  width = 2
}


 Juanma

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <f7ccd24b0809100349i1f0bc4fdy9319f9b82130579@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes:

> I've got two crashes, almost identical to the one above but they crash
> at composite.c:1144 instead:
[...]
> (gdb) p *cmp_it
> $2 = {
>   stop_pos = 1485,
>   id = 5,
>   ch = -2,
[...]
> (gdb) p *cmp_it
> $2 = {
>   stop_pos = 1982,
>   id = 19,
>   ch = -2,

Ah, I've forgotten to reset cmp_it->id to -1 for the case of
cmp_it->ch = -2.  I just installed a fix.  But, as I
couldn't reproduce the segfault with HELLO file, that bag
may not be the reason of your crash.  Anyway, could you
please try again?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> [...]
>
> Ah, I've forgotten to reset cmp_it->id to -1 for the case of
> cmp_it->ch = -2.  I just installed a fix.  But, as I couldn't
> reproduce the segfault with HELLO file, that bag may not be the
> reason of your crash.  Anyway, could you please try again?

I can't reproduce the segfault anymore.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Juanma Barranquero]

On Wed, Sep 10, 2008 at 14:04, Kenichi Handa <handa@m17n.org> wrote:

> Ah, I've forgotten to reset cmp_it->id to -1 for the case of
> cmp_it->ch = -2.  I just installed a fix.  But, as I
> couldn't reproduce the segfault with HELLO file, that bag
> may not be the reason of your crash.  Anyway, could you
> please try again?

Yes, it fixes this crash for me.

  Juanma

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <f7ccd24b0809100719r4b099c93xff05c09378453ac0@mail.gmail.com>, "Juanma Barranquero" <lekktu@gmail.com> writes:

> On Wed, Sep 10, 2008 at 14:04, Kenichi Handa <handa@m17n.org> wrote:
> > Ah, I've forgotten to reset cmp_it->id to -1 for the case of
> > cmp_it->ch = -2.  I just installed a fix.  But, as I
> > couldn't reproduce the segfault with HELLO file, that bag
> > may not be the reason of your crash.  Anyway, could you
> > please try again?

> Yes, it fixes this crash for me.

How about the incorrect cursor moving?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Juanma Barranquero]

On Thu, Sep 11, 2008 at 02:31, Kenichi Handa <handa@m17n.org> wrote:

> How about the incorrect cursor moving?

No problem with the cursor that I can see.

 Juanma

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> In article <f7ccd24b0809100719r4b099c93xff05c09378453ac0@mail.gmail.com>,
> "Juanma Barranquero" <lekktu@gmail.com> writes:
>
>> On Wed, Sep 10, 2008 at 14:04, Kenichi Handa <handa@m17n.org> wrote:
>> > Ah, I've forgotten to reset cmp_it->id to -1 for the case of
>> > cmp_it->ch = -2.  I just installed a fix.  But, as I
>> > couldn't reproduce the segfault with HELLO file, that bag
>> > may not be the reason of your crash.  Anyway, could you
>> > please try again?
>
>> Yes, it fixes this crash for me.
>
> How about the incorrect cursor moving?

This is still there.  See, for example
http://www-users.rwth-aachen.de/torsten.bronger/utf8test.txt.gz

I can't move the cursor freely in this 3-character text file.  It
hangs at the combining tilde accent.

By the way, the problem that longlines-mode stops processing at the
first diacritic is gone.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <87hc8ntdlp.fsf@physik.rwth-aachen.de>, Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> > How about the incorrect cursor moving?

> This is still there.  See, for example
> http://www-users.rwth-aachen.de/torsten.bronger/utf8test.txt.gz

> I can't move the cursor freely in this 3-character text file.  It
> hangs at the combining tilde accent.

Sigh.  I still can't reproduce it both with and without
m17n-lib/libotf.  What does "hangs" exactly means?  Emacs
hangs and no more key is accepted?  Or, just the cursor
doesn't move to the next of tilde accent?

If Emacs hangs, please reproduce it under gdb and check at
which code Emacs chokes.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> In article <87hc8ntdlp.fsf@physik.rwth-aachen.de>, Torsten Bronger
> <bronger@physik.rwth-aachen.de> writes:
>
>> > How about the incorrect cursor moving?
>
>> This is still there.  See, for example
>> http://www-users.rwth-aachen.de/torsten.bronger/utf8test.txt.gz
>
>> I can't move the cursor freely in this 3-character text file.  It
>> hangs at the combining tilde accent.
>
> Sigh.  I still can't reproduce it both with and without
> m17n-lib/libotf.  What does "hangs" exactly means?  Emacs
> hangs and no more key is accepted?  Or, just the cursor
> doesn't move to the next of tilde accent?

No, Emacs doesn't hang.  I just can only pass the character with the
cursor rightwards.  If I press on the left arrow key for moving back
to the beginning of the file, movement stops at the diacritic
character.  I still can go back to the right or bottom, but I can't
get *before* the diacritic.

If I jump upwards with PgUp, this works at first.  However, pressing
an arbitrary arrow key jumps downwards to the diacritic character.
It feels like a wall for the cursor, permeable only in one
direction.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Kenichi Handa]

In article <87wshiswyb.fsf@physik.rwth-aachen.de>, Torsten Bronger <bronger@physik.rwth-aachen.de> writes:

> No, Emacs doesn't hang.  I just can only pass the character with the
> cursor rightwards.  If I press on the left arrow key for moving back
> to the beginning of the file, movement stops at the diacritic
> character.  I still can go back to the right or bottom, but I can't
> get *before* the diacritic.

> If I jump upwards with PgUp, this works at first.  However, pressing
> an arbitrary arrow key jumps downwards to the diacritic character.
> It feels like a wall for the cursor, permeable only in one
> direction.

The following change may fix your problem.  Please try again
with the latest code.

2008-09-17  Romain Francoise  <romain@orebokech.com>

	* composite.c (composition_adjust_point): Fix int/EMACS_INT mixup.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: [Torsten Bronger] 23.0.60; Unicode display problems

[Torsten Bronger]

Hallöchen!

Kenichi Handa writes:

> In article <87wshiswyb.fsf@physik.rwth-aachen.de>, Torsten Bronger
> <bronger@physik.rwth-aachen.de> writes:
>
>> No, Emacs doesn't hang.  I just can only pass the character with
>> the cursor rightwards.  [...]
>>
>> [...]  It feels like a wall for the cursor, permeable only in one
>> direction.
>
> The following change may fix your problem.  Please try again with
> the latest code.
>
> 2008-09-17  Romain Francoise  <romain@orebokech.com>
>
> 	* composite.c (composition_adjust_point): Fix int/EMACS_INT mixup.

Yes, I don't see these problems anymore.

Tschö,
Torsten.

-- 
Torsten Bronger, aquisgrana, europa vetus
                   Jabber ID: torsten.bronger@jabber.rwth-aachen.de