Stefan Schimanski wrote:
Hi!
Before playing the patchwork game again in fixing the bugs in the
subject and, without noticing, introducing a hand full new bugs, here
are some patches which clean up the bidi mess:
I'm getting a crash as soon as I try typing in to a new document with
these patches... trace attached. (I may have misapplied the patches, see
my last remark below...)
The Bidi class mainly offers the isBoundary method whose use is spread
over the LyX code. Unfortunately it needs a valid cache of the bidi
boundaries. To produce that it needs a valid Row object, which in turn
needs valid paragraph metrics which are not available after many cursor
operations. Ignoring this fact leads to #3790, #3801 and #3809.
* So the only clean approach is to rip out all bidi references from the
code and finally use the Font information of each position which also
holds the RTL/LTR flag. This is done by nobidi.patch (see below).
This sounds reasonable, I just want to make sure it works in practice.
But it looks good.
* Then we can implement Text::setCurrentFont without any reference to
Text::bidi and by that fix all the mentioned bugs, implemented in
setcurrentfontnobidi.patch.
Same as above, but I would want to test it quite carefully first.
* Finally we should fix the
spaces-around-RTL-segments-in-LTR-paragraphs-problem (and the symmetric
case). While playing around with the cursor left/right on RTL/LTR
boundaries, trying to write mixed bidi text and continuing after a
boundary, I am very much convinced now that the already mentioned
approach of rtlspaces.patch and rtlepgnobidi.patch is right thing to do.
I will produce a small demonstration in another mail.
Can we keep the discussion of RTL spaces separate from the discussion of
how to solve the crash? Unless they're very closely intertwined, I think
it would be easier that way, and I suggest we continue the discussion
about rtlspaces elsewhere (i.e., the thread in the users' list). So I
responded to the spaces issue there.
One relevant point from there to here, though: I'm not sure you'll be
able to do away with bidi entirely. For example, as I suggest in that
thread, for "visual mode" I think we'll have to use vis2log and log2vis.
And once we're using anything Bidi related in cursor movement, we'll
have to solve the problem for that anyway; so is it still worth going
through with all this? It'll just make us have the bidi logic in *two*
places instead of one, and in a slightly different form, to boot...
-------
Finally, Stefan, one general remark:
It's hard to follow multiple patches at once, especially if they are not
totally separated in a logical way (for example, I'm pretty sure that
nobidi.patch includes a change which actually belongs in
rtlepmnobidi.patch --- specifically the change at hunk @@ -1161,7
+1153,8 @@ in Text2.cpp) --- and they also don't apply cleanly over each
other because of that...
I very warmly recommend using "quilt" (the best place I've found for
getting started with it is here:
http://www.coffeebreaks.org/blogs/wp-content/archives/talks/2005/quilt/quiltintro-s5.html)
--- I only started using it about a month ago, and I already can't
understand how one can develop code without it. It is a wonderful tool
aimed specifically at making it easier to handle multiple patches. It'll
take you at most a few days to get used to, and it makes life so much
easier. There are also a few alternatives mentioned, I haven't tried
them myself, though...
But however it's done, it's really important to keep the different
patches separate from each other...
Dov
#0 0xb718e867 in raise () from /lib/libc.so.6
#1 0xb71900d8 in abort () from /lib/libc.so.6
#2 0xb7313899 in __gnu_debug::_Error_formatter::_M_error ()
from /usr/lib/libstdc++.so.6
#3 0x081b29c3 in lyx::Cursor::getFont (this=0x8dccc28)
at
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/debug/vector:199
#4 0x08136a3e in lyx::BufferView::fitCursor (this=0x8dcca00)
at BufferView.cpp:323
#5 0x08138ccb in lyx::BufferView::update (this=0x8dcca00, flags=13)
at BufferView.cpp:410
#6 0x0830c4c1 in lyx::LyXFunc::dispatch (this=0x8cf3550, [EMAIL PROTECTED])
at LyXFunc.cpp:1793
#7 0x0830dd63 in lyx::LyXFunc::processKeySym (this=0x8cf3550,
[EMAIL PROTECTED], state=lyx::key_modifier::none) at LyXFunc.cpp:373
#8 0x0869574d in lyx::frontend::WorkArea::processKeySym (this=0x8d744ac,
[EMAIL PROTECTED], state=lyx::key_modifier::none) at WorkArea.cpp:177
#9 0x08705522 in lyx::frontend::GuiWorkArea::keyPressEvent (this=0x8d74498,
e=0xbfed5314) at GuiWorkArea.cpp:474
#10 0xb7a19e11 in QWidget::event () from /usr/lib/libQtGui.so.4
#11 0xb7c9ac84 in QFrame::event () from /usr/lib/libQtGui.so.4
#12 0xb7d0f8af in QAbstractScrollArea::event () from /usr/lib/libQtGui.so.4
#13 0xb79d059f in QApplicationPrivate::notify_helper ()
from /usr/lib/libQtGui.so.4
#14 0xb79d3318 in QApplication::notify () from /usr/lib/libQtGui.so.4
#15 0x086ebdf0 in lyx::frontend::GuiApplication::notify (this=0x8cf6f08,
receiver=0x8d74498, event=0xbfed5314) at GuiApplication.cpp:237
#16 0xb7a1ff3e in QApplication::topLevelAt () from /usr/lib/libQtGui.so.4
#17 0xb7a4afe6 in QX11Info::copyX11Data () from /usr/lib/libQtGui.so.4
#18 0xb7a4cdd1 in QX11Info::copyX11Data () from /usr/lib/libQtGui.so.4
#19 0xb7a2a428 in QApplication::x11ProcessEvent () from /usr/lib/libQtGui.so.4
#20 0xb7a4e1f8 in QX11Info::copyX11Data () from /usr/lib/libQtGui.so.4
#21 0xb75aab51 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#22 0xb75adbc6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#23 0xb75ae147 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#24 0xb773e648 in QEventDispatcherGlib::processEvents ()
from /usr/lib/libQtCore.so.4
#25 0xb7a4dfe5 in QX11Info::copyX11Data () from /usr/lib/libQtGui.so.4
#26 0xb771a231 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4
#27 0xb771a33a in QEventLoop::exec () from /usr/lib/libQtCore.so.4
#28 0xb771c6f6 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4
#29 0xb79d0017 in QApplication::exec () from /usr/lib/libQtGui.so.4
#30 0x086eafd8 in lyx::frontend::GuiApplication::exec (this=0x8cf6f08)
at GuiApplication.cpp:158
#31 0x082e4113 in lyx::LyX::exec (this=0xbfed64bc, [EMAIL PROTECTED],
argv=0xbfed6574) at LyX.cpp:463
#32 0x0806a36e in main (argc=1, argv=Cannot access memory at address 0x7681
) at main.cpp:48
