Package: emacs;
Reported by: Thamer Mahmoud <thamer.mahmoud <at> gmail.com>
Date: Wed, 8 Sep 2010 11:20:02 UTC
Severity: normal
Found in version 24.0.50
Done: Thamer Mahmoud <thamer.mahmoud <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6998 in the body.
You can then email your comments to 6998 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#6998; Package emacs.
(Wed, 08 Sep 2010 11:20:02 GMT) Full text and rfc822 format available.Thamer Mahmoud <thamer.mahmoud <at> gmail.com>:bug-gnu-emacs <at> gnu.org.
(Wed, 08 Sep 2010 11:20:03 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> To: bug-gnu-emacs <at> gnu.org Subject: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Date: Wed, 8 Sep 2010 11:39:06 +0300
While investigating a crash I came across this problem.
By default in Emacs, lines starting with Other Neutral types (in this
case `*') seem to be following the direction of the line before them,
and perhaps not being considered as separate paragraphs. This makes
Emacs display files differently than the output of fribidi (gedit,
etc).
For example, I have a file with the following content:
* ARABIC
* abcdef
I'd expect to see:
CIBARA *
* abcdef
But in Emacs it's shown as:
CIBARA *
abcdef *
Another example is:
* First
[BLANK_LINE]
ARABIC
* Second
What I expect:
* First
[BLANK_LINE]
CIBARA
* Second
What is shown in Emacs:
* First
[BLANK_LINE]
CIBARA
Second *
This seems like a bug to me.
Tests were done using -Q --eval "(setq-default bidi-display-reordering t)".
In GNU Emacs 24.0.50.6 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
of 2010-09-07
Thanks.
--
Thamer
Thamer Mahmoud <thamer.mahmoud <at> gmail.com>:Thamer Mahmoud <thamer.mahmoud <at> gmail.com>:Message #10 received at 6998-done <at> debbugs.gnu.org (full text, mbox):
From: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> To: 6998-done <at> debbugs.gnu.org Subject: Re: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Date: Sat, 11 Sep 2010 01:29:44 +0300
I did some testing, and I found out that the differences between Emacs and other apps (fribidi, gedit, kwrite, etc) are explained by the other apps' use of "line-based reordering", while Emacs uses "paragraph-based reordering" (perhaps to avoid filled paragraphs having more than one direction). So I guess this is not a bug per se. However, I still see inconsistent rendering of the second example given above. But I'll file a more specific bug for that. Closing. -- Thamer
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#6998; Package emacs.
(Mon, 13 Sep 2010 12:03:01 GMT) Full text and rfc822 format available.Message #13 received at 6998 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> Cc: 6998 <at> debbugs.gnu.org, thamer.mahmoud <at> gmail.com Subject: Re: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Date: Mon, 13 Sep 2010 14:04:53 +0200
> Date: Sat, 11 Sep 2010 01:29:44 +0300 > From: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> > Cc: > > I did some testing, and I found out that the differences between Emacs > and other apps (fribidi, gedit, kwrite, etc) are explained by the other > apps' use of "line-based reordering", while Emacs uses > "paragraph-based reordering" (perhaps to avoid filled paragraphs > having more than one direction). More accurately, the "paragraph" in fribidi etc. is a single line, because a linefeed is one of the paragraph separators. Since this would produce non-sensical display in any human-readable text that uses hard newlines, and because Emacs uses hard newlines in just about every derivative of Text mode, the Emacs implementation of the Unicode Bidirectional Algorithm uses what UAX#9 calls ``higher-level protocols'' to define what is the base embedding level of a paragraph. In Emacs, a paragraph is delimited by lines that are entirely whitespace or empty. This is explained in the "Bidirectional Editing" node of the Emacs manual. > So I guess this is not a bug per se. Right, not a bug; a feature. > However, I still see inconsistent rendering of the second example > given above. But I'll file a more specific bug for that. If you mean this example: > * First > [BLANK_LINE] > ARABIC > * Second > > What I expect: > > * First > [BLANK_LINE] > CIBARA > * Second > > What is shown in Emacs: > > * First > [BLANK_LINE] > CIBARA > Second * Then it is also expected behavior: since there's no blank line between "ARABIC" and "* Second", the latter is considered to belong to a right-to-left paragraph, and rendered accordingly. OTOH, "* First" and "ARABIC" _are_ separated by a blank line, so they belong to different paragraphs. You can control the paragraph direction by inserting the LRM and RLM characters in front of each paragraph. Alternatively, you can force a specific base direction on the entire buffer by setting the per-buffer variable bidi-paragraph-direction. This is also described in the manual.
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#6998; Package emacs.
(Mon, 20 Sep 2010 14:44:01 GMT) Full text and rfc822 format available.Message #16 received at 6998 <at> debbugs.gnu.org (full text, mbox):
From: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 6998 <at> debbugs.gnu.org Subject: Re: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Date: Mon, 20 Sep 2010 17:45:00 +0300
Eli Zaretskii writes:
>
> If you mean this example:
>
> > * First
> > [BLANK_LINE]
> > ARABIC
> > * Second
> >
> > What I expect:
> >
> > * First
> > [BLANK_LINE]
> > CIBARA
> > * Second
> >
> > What is shown in Emacs:
> >
> > * First
> > [BLANK_LINE]
> > CIBARA
> > Second *
>
> Then it is also expected behavior: since there's no blank line between
> "ARABIC" and "* Second", the latter is considered to belong to a
> right-to-left paragraph, and rendered accordingly.
Thanks for your comments, Eli. I do mean the above example, as I can
see some inconsistent behavior when using org-mode.
It seems that Emacs _sometimes_ renders the above example in org-mode
as,
* First...
* Second
While in other invocations the same file is rendered as:
* First...
Second *
This behavior is not always reproducible. In X11, I have used the
following command to start 5 Emacs sessions with some having the first
rendering and others the second rendering:
i=5; while [ $i -gt 0 ] ; do ./emacs -Q --eval "(setq-default bidi-display-reordering t)" example2.org & let i=i-1; done;
I can also see a bug and a crash with the second rendering (and it got
me confused about how Emacs handles neutral types), so I wonder which
rendering should be considered as "correct"?
--
Thamer
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#6998; Package emacs.
(Mon, 20 Sep 2010 19:06:02 GMT) Full text and rfc822 format available.Message #19 received at 6998 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> Cc: 6998 <at> debbugs.gnu.org Subject: Re: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Date: Mon, 20 Sep 2010 21:07:49 +0200
> Date: Mon, 20 Sep 2010 17:45:00 +0300
> From: Thamer Mahmoud <thamer.mahmoud <at> gmail.com>
> Cc: 6998 <at> debbugs.gnu.org
>
> Thanks for your comments, Eli. I do mean the above example, as I can
> see some inconsistent behavior when using org-mode.
A reproducible test case, preferably starting with "emacs -Q", would
be greatly appreciated.
> It seems that Emacs _sometimes_ renders the above example in org-mode
> as,
>
> * First...
> * Second
>
> While in other invocations the same file is rendered as:
>
> * First...
> Second *
Sorry, I don't understand. Your original example included a line in
ARABIC and an empty line, in addition to "First" and "second" lines.
Are we talking about a different example now? If not, please show how
the example is rendered in its entirety, in the two different
behaviors you observe.
> I can also see a bug and a crash with the second rendering (and it got
> me confused about how Emacs handles neutral types)
Could you pots a backtrace when in crashes?
> so I wonder which rendering should be considered as "correct"?
For your original example:
* First
[BLANK_LINE]
ARABIC
* Second
the correct rendering is this:
* First
[BLANK_LINE]
CIBARA
Second *
For the example you show now:
* First
* Second
the correct rendering is what you'd expect:
* First
* Second
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#6998; Package emacs.
(Wed, 22 Sep 2010 02:57:02 GMT) Full text and rfc822 format available.Message #22 received at 6998 <at> debbugs.gnu.org (full text, mbox):
From: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: 6998 <at> debbugs.gnu.org Subject: Re: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Date: Wed, 22 Sep 2010 05:58:25 +0300
[Message part 1 (text/plain, inline)]
Eli Zaretskii writes:
> A reproducible test case, preferably starting with "emacs -Q", would
> be greatly appreciated.
>
Note that both the crash and the bug (mentioned further below) were
not reproducible on a virtual Windows XP.
To reproduce this crash:
1. Open attached test case with: emacs -Q --eval "(setq-default bidi-display-reordering t)" wrap_crash.org
It should open in org-mode by default.
2. Emacs _sometimes_ would render it like this:
* First...
...Second *
If not, repeat step one until it does, or use something similar to
the command I provided in my last message, etc.
3. Once you see the above, do: M-x visual-line-mode [ENTER] C-n C-n
> > It seems that Emacs _sometimes_ renders the above example in org-mode
> > as,
> >
> > * First...
> > * Second
> >
> > While in other invocations the same file is rendered as:
> >
> > * First...
> > Second *
>
> Sorry, I don't understand. Your original example included a line in
> ARABIC and an empty line, in addition to "First" and "second" lines.
> Are we talking about a different example now?
No, it's the same example just viewed using org-mode (which considers
lines that start with `*' as headers, and does some folding).
> For the example you show now:
>
> * First
> * Second
>
> the correct rendering is what you'd expect:
>
> * First
> * Second
Would this apply to org-mode wrt to the attached testcase?
As a side bug, if you position cursor on "* First" in the testcase
then press [TAB] you will see that "* Second" gets deformed to:
d *...
Testcase and backtrace attached. Thanks.
[wrap_crash.org (text/plain, inline)]
* First عربي * Second عربي
[wrap_crash_backtrace.txt (text/plain, inline)]
bt full
#0 abort () at emacs.c:427
No locals.
#1 0x080f4aa0 in bidi_level_of_next_char (bidi_it=0xbfffdd3c) at bidi.c:1492
type = UNKNOWN_BT
level = 0
prev_level = -1
next_for_neutral = {
bytepos = 21,
charpos = 17,
type = UNKNOWN_BT,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
}
#2 0x080f5079 in bidi_move_to_visually_next (bidi_it=0xbfffdd3c) at bidi.c:1689
old_level = 2
new_level = 0
next_level = 0
sentinel = {
bytepos = 0,
charpos = 0,
ch = 0,
ch_len = 0,
type = UNKNOWN_BT,
type_after_w1 = STRONG_R,
orig_type = UNKNOWN_BT,
resolved_level = 0,
invalid_levels = 0,
invalid_rl_levels = 1,
prev_was_pdf = 26,
prev = {
bytepos = 22,
charpos = 100,
type = STRONG_L,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
last_strong = {
bytepos = 1,
charpos = 2,
type = UNKNOWN_BT,
type_after_w1 = 4294967295,
orig_type = UNKNOWN_BT
},
next_for_neutral = {
bytepos = 25,
charpos = 21,
type = STRONG_L,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
prev_for_neutral = {
bytepos = 25,
charpos = 21,
type = STRONG_L,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
next_for_ws = {
bytepos = 21,
charpos = 17,
type = UNKNOWN_BT,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
next_en_pos = 25,
ignore_bn_limit = 21,
sor = L2R,
scan_dir = 1,
stack_idx = 1,
level_stack = {{
level = 0,
override = NEUTRAL_DIR
}, {
level = 0,
override = NEUTRAL_DIR
}, {
level = 0,
override = 4294967295
}, {
level = 0,
override = R2L
}, {
level = -1,
override = NEUTRAL_DIR
}, {
level = 1,
override = NEUTRAL_DIR
}, {
level = 0,
override = NEUTRAL_DIR
} <repeats 58 times>},
first_elt = 0,
paragraph_dir = NEUTRAL_DIR,
new_paragraph = 0,
separator_limit = 0
}
#3 0x0807990c in set_iterator_to_next (it=0xbfffd79c, reseat_p=1) at xdisp.c:6206
prev_scan_dir = -1
#4 0x0807cb7a in move_it_to (it=0xbfffd79c, to_charpos=22, to_x=-1, to_y=-1, to_vpos=-1, op=8) at xdisp.c:7568
skip = MOVE_NEWLINE_OR_CR
skip2 = MOVE_X_REACHED
line_height = -1073749936
line_start_x = 0
reached = 0
#5 0x0807258b in start_display (it=0xbfffd79c, w=0x86f29b8, pos=...) at xdisp.c:2851
new_x = -1213421424
start_at_line_beg_p = 0
first_y = 0
row = 0x8ade608
first_vpos = 0
#6 0x081ad97f in Fvertical_motion (lines=4, window=141502909) at indent.c:2044
it_start = -1073749976
first_x = 134923737
it_overshoot_expected = 138805418
it = {
window = 141502909,
w = 0x86f29b8,
f = 0x86f2830,
method = GET_FROM_BUFFER,
stop_charpos = 23,
prev_stop = 0,
base_level_stop = 0,
end_charpos = 29,
s = 0x0,
string_nchars = 0,
region_beg_charpos = -1,
region_end_charpos = -1,
redisplay_end_trigger_charpos = 0,
multibyte_p = 1,
header_line_p = 0,
string_from_display_prop_p = 0,
ellipsis_p = 0,
avoid_cursor_p = 0,
dp = 0x0,
dpvec = 0x0,
dpend = 0x0,
dpvec_char_len = 0,
dpvec_face_id = 0,
saved_face_id = 13,
ctl_chars = {0 <repeats 16 times>},
start = {
pos = {
charpos = 22,
bytepos = 26
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
},
current = {
pos = {
charpos = 22,
bytepos = 26
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
},
n_overlay_strings = 0,
overlay_strings = {0 <repeats 16 times>},
string_overlays = {0 <repeats 16 times>},
string = 138805418,
from_overlay = 0,
stack = {{
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
comp = {
object = 0
},
stretch = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0,
string_from_display_prop_p = 0,
display_ellipsis_p = 0,
avoid_cursor_p = 0,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}},
sp = 0,
selective = 0,
what = IT_CHARACTER,
face_id = 13,
selective_display_ellipsis_p = 1,
ctl_arrow_p = 1,
face_box_p = 0,
start_of_box_run_p = 0,
end_of_box_run_p = 0,
overlay_strings_at_end_processed_p = 0,
ignore_overlay_strings_at_pos_p = 0,
glyph_not_available_p = 0,
starts_in_middle_of_char_p = 0,
face_before_selective_p = 0,
constrain_row_ascent_descent_p = 0,
line_wrap = WORD_WRAP,
base_face_id = 0,
c = 100,
len = 1,
cmp_it = {
stop_pos = 15,
id = -1,
ch = -2,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = 0,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
char_to_display = 100,
image_id = 0,
slice = {
x = 138805418,
y = 138805418,
width = 138805418,
height = 138805418
},
space_width = 138805418,
voffset = 0,
tab_width = 8,
font_height = 138805418,
object = 143782445,
position = {
charpos = 22,
bytepos = 26
},
truncation_pixel_width = 0,
continuation_pixel_width = 0,
first_visible_x = 0,
last_visible_x = 984,
last_visible_y = 646,
extra_line_spacing = 0,
max_extra_line_spacing = 0,
override_ascent = -1,
override_descent = 0,
override_boff = 0,
glyph_row = 0x8ade608,
area = TEXT_AREA,
nglyphs = 1,
pixel_width = 8,
ascent = 13,
descent = 4,
max_ascent = 13,
max_descent = 4,
phys_ascent = 11,
phys_descent = 0,
max_phys_ascent = 11,
max_phys_descent = 0,
current_x = 16,
continuation_lines_width = 0,
eol_pos = {
charpos = 0,
bytepos = 0
},
current_y = 0,
first_vpos = 0,
vpos = 0,
hpos = 2,
left_user_fringe_bitmap = 0,
right_user_fringe_bitmap = 0,
left_user_fringe_face_id = 0,
right_user_fringe_face_id = 0,
bidi_p = 1,
bidi_it = {
bytepos = 26,
charpos = 22,
ch = 100,
ch_len = 1,
type = STRONG_L,
type_after_w1 = STRONG_L,
orig_type = STRONG_L,
resolved_level = 2,
invalid_levels = 0,
invalid_rl_levels = -1,
prev_was_pdf = 0,
prev = {
bytepos = 25,
charpos = 21,
type = STRONG_L,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
last_strong = {
bytepos = 25,
charpos = 21,
type = STRONG_L,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
next_for_neutral = {
bytepos = 21,
charpos = 17,
type = UNKNOWN_BT,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
prev_for_neutral = {
bytepos = 25,
charpos = 21,
type = STRONG_L,
type_after_w1 = STRONG_L,
orig_type = STRONG_L
},
next_for_ws = {
bytepos = 0,
charpos = 0,
type = UNKNOWN_BT,
type_after_w1 = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
next_en_pos = -1,
ignore_bn_limit = 0,
sor = R2L,
scan_dir = -1,
stack_idx = 0,
level_stack = {{
level = 1,
override = NEUTRAL_DIR
}, {
level = 0,
override = NEUTRAL_DIR
} <repeats 63 times>},
first_elt = 0,
paragraph_dir = R2L,
new_paragraph = 0,
separator_limit = -1
},
paragraph_embedding = NEUTRAL_DIR
}
pt = {
charpos = 22,
bytepos = 26
}
w = 0x86f29b8
old_buffer = 138805418
gcpro1 = {
next = 0x8ba1208,
var = 0xb7aca470,
nvars = -1213422480
}
lcols = 139263071
cols = 0
#7 0x081e739f in Ffuncall (nargs=2, args=0xbfffe100) at eval.c:2993
fun = 136848109
original_fun = 138942282
funcar = 136119380
numargs = 1
lisp_numargs = 146769790
val = -1073749784
backtrace = {
next = 0xbfffe360,
function = 0xbfffe100,
args = 0xbfffe104,
nargs = 1,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0xbfffe050
i = 2
#8 0x082265cf in Fbyte_code (bytestr=137280161, vector=137280181, maxdepth=20) at bytecode.c:679
count = 13
op = 1
vectorp = 0x82ebab8
bytestr_length = 178
stack = {
pc = 0x83d14ce "\016\032U\203\233",
top = 0xbfffe104,
bottom = 0xbfffe100,
byte_string = 137280161,
byte_string_start = 0x83d1451 "`\306 \307\030\031\032\v:\203)",
constants = 137280181,
next = 0xbfffe3f0
}
top = 0xbfffe100
result = 138805418
#9 0x081e7b74 in funcall_lambda (fun=137280125, nargs=2, arg_vector=0xbfffe3c4) at eval.c:3174
val = 138805418
syms_left = 138805418
next = 139163650
count = 11
i = 2
optional = 1
rest = 0
#10 0x081e759e in Ffuncall (nargs=3, args=0xbfffe3c0) at eval.c:3036
fun = 137280125
original_fun = 139924906
funcar = 136119380
numargs = 2
lisp_numargs = 141033928
val = 0
backtrace = {
next = 0xbfffe610,
function = 0xbfffe3c0,
args = 0xbfffe3c4,
nargs = 2,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0x2
i = -1073748364
#11 0x082265cf in Fbyte_code (bytestr=137280017, vector=137280037, maxdepth=16) at bytecode.c:679
count = 11
op = 2
vectorp = 0x82eba28
bytestr_length = 59
stack = {
pc = 0x83d1546 "\207\316\n\r\016\017#\207",
top = 0xbfffe3c8,
bottom = 0xbfffe3c0,
byte_string = 137280017,
byte_string_start = 0x83d1513 "\b\205 ",
constants = 137280037,
next = 0xbfffe6b0
}
top = 0xbfffe3c0
result = -1217735736
#12 0x081e7b74 in funcall_lambda (fun=137279965, nargs=4, arg_vector=0xbfffe674) at eval.c:3174
val = 139065208
syms_left = 138805418
next = 139924762
count = 7
i = 4
optional = 1
rest = 0
#13 0x081e759e in Ffuncall (nargs=5, args=0xbfffe670) at eval.c:3036
fun = 137279965
original_fun = 139924786
funcar = -1215831512
numargs = 4
lisp_numargs = 0
val = -1073748296
backtrace = {
next = 0xbfffe8c8,
function = 0xbfffe670,
args = 0xbfffe674,
nargs = 4,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0x2
i = 136469991
#14 0x082265cf in Fbyte_code (bytestr=137279217, vector=137279245, maxdepth=20) at bytecode.c:679
count = 7
op = 4
vectorp = 0x82eb710
bytestr_length = 7
stack = {
pc = 0x83d170c "\207",
top = 0xbfffe680,
bottom = 0xbfffe670,
byte_string = 137279217,
byte_string_start = 0x83d1706 "\302\bÉ\t$\207",
constants = 137279245,
next = 0xbfffea90
}
top = 0xbfffe670
result = -1073748040
#15 0x081e6361 in Feval (form=137279206) at eval.c:2358
numargs = 12
args_left = 138805418
i = 136469991
maxargs = 3
argvals = {137279217, 137279245, 20, 138805418, 138805418, 0, 0, -1073747484}
fun = 138485149
val = 12
original_fun = 138930242
original_args = 137279214
funcar = -1073747828
backtrace = {
next = 0xbfffecb0,
function = 0xbfffe8e0,
args = 0xbfffe884,
nargs = 3,
evalargs = 1 '\001',
debug_on_exit = 0 '\000'
}
gcpro1 = {
next = 0xbfffe848,
var = 0x839122a,
nvars = 0
}
gcpro2 = {
next = 0x816c718,
var = 0x1,
nvars = -1073747132
}
gcpro3 = {
next = 0x0,
var = 0xbfffe884,
nvars = 3
}
#16 0x081e4b82 in internal_lisp_condition_case (var=139166106, bodyform=137279206, handlers=137279270) at eval.c:1407
val = 138805418
c = {
tag = 138805418,
val = 138805418,
next = 0xbffff1a4,
gcpro = 0x0,
jmp = {{
__jmpbuf = {-1073746588, -1073746584, -1073744732, -1073747400, 1672471279, -1595400832},
__mask_was_saved = 0,
__saved_mask = {
__val = {3221220164, 3221219476, 3221222564, 3221219896, 136213374, 138921242, 142554630, 3221219476, 396883, 0, 0, 0, 138805418, 0, 0, 3221219368, 4294967266, 497502, 0, 332839, 1285052478, 446709, 0, 332839, 11, 3221220528, 3221219920, 3221219924, 1, 0, 138479965, 138922218}
}
}},
backlist = 0xbfffecb0,
handlerlist = 0xbffff190,
lisp_eval_depth = 2,
pdlcount = 7,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0xbfffea90
}
h = {
handler = 137279270,
var = 139166106,
chosen_clause = 138805418,
tag = 0xbfffe960,
next = 0xbffff190
}
#17 0x08227325 in Fbyte_code (bytestr=137279113, vector=137279133, maxdepth=24) at bytecode.c:869
handlers = 137279270
body = 137279206
count = 7
op = 143
vectorp = 0x82eb6a0
bytestr_length = 78
stack = {
pc = 0x83d174f "\210\202L",
top = 0xbfffea50,
bottom = 0xbfffea50,
byte_string = 137279113,
byte_string_start = 0x83d170e "\b\204\006",
constants = 137279133,
next = 0x0
}
top = 0xbfffea50
result = 138222001
#18 0x081e7b74 in funcall_lambda (fun=137279061, nargs=2, arg_vector=0xbfffed64) at eval.c:3174
val = 141607232
syms_left = 138805418
next = 139924762
count = 5
i = 2
optional = 1
rest = 0
#19 0x081e759e in Ffuncall (nargs=3, args=0xbfffed60) at eval.c:3036
fun = 137279061
original_fun = 139063306
funcar = 135674684
numargs = 2
lisp_numargs = 138805418
val = 138805418
backtrace = {
next = 0xbfffefd0,
function = 0xbfffed60,
args = 0xbfffed64,
nargs = 2,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0xbfffed68
i = 3
#20 0x081e2a8c in Fcall_interactively (function=139063306, record_flag=138805418, keys=138833597) at callint.c:849
val = 0
args = 0xbfffed60
visargs = 0xbfffed40
specs = 137279345
filter_specs = 137279345
teml = 0
up_event = 138805418
enable = 138805418
speccount = 3
next_event = 1
prefix_arg = 138805418
string = 0xbfffed81 "p\np"
tem = 0x827511c ""
varies = 0xbfffed20
i = 3
j = 3
count = 2
foo = 0
prompt1 = '\000' <repeats 99 times>
tem1 = 0x0
arg_from_tty = 0
gcpro1 = {
next = 0x8579d72,
var = 0x3,
nvars = 0
}
gcpro2 = {
next = 0x81771b8,
var = 0x84600aa,
nvars = 138805418
}
gcpro3 = {
next = 0x3,
var = 0x84600aa,
nvars = 3
}
gcpro4 = {
next = 0xbfffee60,
var = 0xbfffed38,
nvars = 3
}
gcpro5 = {
next = 0xbffff704,
var = 0xbffff4a4,
nvars = -1073746408
}
key_count = 1
record_then_fail = 0
save_this_command = 139063306
save_last_command = 139063306
save_this_original_command = 139063306
save_real_this_command = 139063306
#21 0x081e73c9 in Ffuncall (nargs=4, args=0xbffff030) at eval.c:2996
fun = 138479653
original_fun = 138930434
funcar = 0
numargs = 3
lisp_numargs = 0
val = 0
backtrace = {
next = 0x0,
function = 0xbffff030,
args = 0xbffff034,
nargs = 3,
evalargs = 0 '\000',
debug_on_exit = 0 '\000'
}
internal_args = 0xbffff034
i = 136187689
#22 0x081e6ef9 in call3 (fn=138930434, arg1=139063306, arg2=138805418, arg3=138805418) at eval.c:2820
ret_ungc_val = 137279061
gcpro1 = {
next = 0x8bf8ebe,
var = 0x8466212,
nvars = 4
}
args = {138930434, 139063306, 138805418, 138805418}
#23 0x08172d86 in Fcommand_execute (cmd=139063306, record_flag=138805418, keys=138805418, special=138805418) at keyboard.c:10336
final = 137279061
tem = 138805418
prefixarg = 138805418
#24 0x0816487b in command_loop_1 () at keyboard.c:1737
scount = 2
cmd = 139063306
keybuf = {56, -1073745664, -1208042826, -1223292826, 134550357, -1225353448, 134548642, -1225321128, -1073807358, -1208019440, 134548642, -1221756944, -1207963660, 0, -1073745648, -1073745920, 0, 0, 138805418, 139951674, 137103213, 138782518, 0, 0, 0, 0, -1223352892, -1207977828, -1073745580, 0}
i = 1
prev_modiff = 11
prev_buffer = 0x891f228
already_adjusted = 0
#25 0x081e4c96 in internal_condition_case (bfun=0x81641a9 <command_loop_1>, handlers=138836402, hfun=0x8163b90 <cmd_error>) at eval.c:1460
val = 138782518
c = {
tag = 138805418,
val = 138805418,
next = 0xbffff2b8,
gcpro = 0x0,
jmp = {{
__jmpbuf = {-1073744000, -1073744124, -1073744732, -1073745288, 1671332591, -1595547264},
__mask_was_saved = 0,
__saved_mask = {
__val = {0, 3071647572, 0, 3221222000, 3221221928, 3221221940, 134550357, 3087005944, 0, 3069646168, 3221159938, 134549363, 134548642, 3073210352, 3087003636, 3071613396, 39, 3221221708, 3086925926, 138721120, 138721248, 3221222244, 3071630884, 3073210440, 2, 4294967295, 3087003636, 134549363, 1, 3221222016, 3086943894, 3087006384}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 138836402,
var = 138805418,
chosen_clause = 134524876,
tag = 0xbffff1a4,
next = 0x0
}
#26 0x08163f04 in command_loop_2 (ignore=138805418) at keyboard.c:1338
val = -1073744000
#27 0x081e4775 in internal_catch (tag=138834474, func=0x8163ee0 <command_loop_2>, arg=138805418) at eval.c:1204
c = {
tag = 138834474,
val = 138805418,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {-1073744000, -1073744124, -1073744732, -1073745016, 1670955759, -1594667136},
__mask_was_saved = 0,
__saved_mask = {
__val = {0 <repeats 16 times>, 3072046750, 0, 0, 0, 138805418, 3221222280, 136120528, 138493528, 138805418, 138825168, 136543850, 0, 138973168, 3221222280, 136119354, 138825168}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#28 0x08163ec0 in command_loop () at keyboard.c:1317
No locals.
#29 0x081637b0 in recursive_edit_1 () at keyboard.c:940
count = 1
val = 134903343
#30 0x0816391a in Frecursive_edit () at keyboard.c:1002
count = 0
buffer = 138805418
#31 0x0816200f in main (argc=5, argv=0xbffff824) at emacs.c:1708
dummy = 0
stack_bottom_variable = -73 '\267'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 8388608,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0xb72d7848 ""
Lisp Backtrace:
"vertical-motion" (0xbfffe104)
"line-move-visual" (0xbfffe3c4)
"line-move" (0xbfffe674)
"byte-code" (0xbfffe884)
"next-line" (0xbfffed64)
"call-interactively" (0xbffff034)
(gdb)
owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:bug#6998; Package emacs.
(Wed, 22 Sep 2010 08:49:01 GMT) Full text and rfc822 format available.Message #25 received at 6998 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> Cc: 6998 <at> debbugs.gnu.org Subject: Re: bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Date: Wed, 22 Sep 2010 10:51:05 +0200
> Date: Wed, 22 Sep 2010 05:58:25 +0300 > From: Thamer Mahmoud <thamer.mahmoud <at> gmail.com> > Cc: 6998 <at> debbugs.gnu.org > > Note that both the crash and the bug (mentioned further below) were > not reproducible on a virtual Windows XP. I didn't see the crash yet, but the display bug you mention near the end of your message is reproducible on my Windows XP box. Thanks. > To reproduce this crash: > > 1. Open attached test case with: emacs -Q --eval "(setq-default bidi-display-reordering t)" wrap_crash.org > It should open in org-mode by default. > > 2. Emacs _sometimes_ would render it like this: > > * First... > ...Second * > > If not, repeat step one until it does, or use something similar to > the command I provided in my last message, etc. "Repeat step one" means invoking Emacs again from the command line? Or killing the buffer and revisiting wrap_crash.org from the same Emacs session? If the former, it sounds strange that a new invocation of Emacs would behave differently from the previous one (unless there's an uninitialized variable somewhere...). > As a side bug, if you position cursor on "* First" in the testcase > then press [TAB] you will see that "* Second" gets deformed to: > > d *... This is related to the ellipsis that Org mode displays instead of lines it hides. If you type "M-x show-all RET", you will see the same display bug. I will work on fixing it, but in general, Org mode should set bidi-paragraph-direction to `left-to-right' in all its buffers, because using "* FOO" outlines with FOO in left-to-right script assumes left-to-right paragraphs, and because Org mode does not enforce an empty line before the "* FOO" lines, making them assume the direction of the previous paragraph, which looks odd.
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Wed, 20 Oct 2010 11:24:04 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.