* bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?
@ 2010-09-08 8:39 Thamer Mahmoud
2010-09-10 22:29 ` Thamer Mahmoud
0 siblings, 1 reply; 7+ messages in thread
From: Thamer Mahmoud @ 2010-09-08 8:39 UTC (permalink / raw)
To: 6998
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?
2010-09-08 8:39 bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Thamer Mahmoud
@ 2010-09-10 22:29 ` Thamer Mahmoud
2010-09-13 12:04 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Thamer Mahmoud @ 2010-09-10 22:29 UTC (permalink / raw)
To: 6998-done
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?
2010-09-10 22:29 ` Thamer Mahmoud
@ 2010-09-13 12:04 ` Eli Zaretskii
2010-09-20 14:45 ` Thamer Mahmoud
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2010-09-13 12:04 UTC (permalink / raw)
To: Thamer Mahmoud; +Cc: 6998, thamer.mahmoud
> Date: Sat, 11 Sep 2010 01:29:44 +0300
> From: Thamer Mahmoud <thamer.mahmoud@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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?
2010-09-13 12:04 ` Eli Zaretskii
@ 2010-09-20 14:45 ` Thamer Mahmoud
2010-09-20 19:07 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Thamer Mahmoud @ 2010-09-20 14:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 6998
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?
2010-09-20 14:45 ` Thamer Mahmoud
@ 2010-09-20 19:07 ` Eli Zaretskii
2010-09-22 2:58 ` Thamer Mahmoud
0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2010-09-20 19:07 UTC (permalink / raw)
To: Thamer Mahmoud; +Cc: 6998
> Date: Mon, 20 Sep 2010 17:45:00 +0300
> From: Thamer Mahmoud <thamer.mahmoud@gmail.com>
> Cc: 6998@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
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?
2010-09-20 19:07 ` Eli Zaretskii
@ 2010-09-22 2:58 ` Thamer Mahmoud
2010-09-22 8:51 ` Eli Zaretskii
0 siblings, 1 reply; 7+ messages in thread
From: Thamer Mahmoud @ 2010-09-22 2:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 6998
[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1670 bytes --]
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.
[-- Attachment #2: testcase --]
[-- Type: text/plain, Size: 41 bytes --]
* First
عربي
* Second
عربي
[-- Attachment #3: backtrace --]
[-- Type: text/plain, Size: 33702 bytes --]
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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction?
2010-09-22 2:58 ` Thamer Mahmoud
@ 2010-09-22 8:51 ` Eli Zaretskii
0 siblings, 0 replies; 7+ messages in thread
From: Eli Zaretskii @ 2010-09-22 8:51 UTC (permalink / raw)
To: Thamer Mahmoud; +Cc: 6998
> Date: Wed, 22 Sep 2010 05:58:25 +0300
> From: Thamer Mahmoud <thamer.mahmoud@gmail.com>
> Cc: 6998@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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-09-22 8:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-08 8:39 bug#6998: 24.0.50; bidi: lines starting with neutral types have the wrong base direction? Thamer Mahmoud
2010-09-10 22:29 ` Thamer Mahmoud
2010-09-13 12:04 ` Eli Zaretskii
2010-09-20 14:45 ` Thamer Mahmoud
2010-09-20 19:07 ` Eli Zaretskii
2010-09-22 2:58 ` Thamer Mahmoud
2010-09-22 8:51 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).