Hi,
If you need help testing the RTL support I'm willing to help as much as I can. I
write most of my files in Hebrew and therefore I use RTL a lot.
I may need a bit of guiding on how to compile the patches... (I don't have much
experience in using patches).
Sincerely,
Ran Rutenberg
Hi Ran (and any other would-be Bidi testers),
Please try out the patches from
http://permalink.gmane.org/gmane.editors.lyx.devel/86921 and let us know
(preferably in a reply to that thread, but I reply to here is also fine)
how you feel about the proposed behavior.
Working with patches is as follows (this is for linux, I don't know how
it's done on other platforms): given a source tree in ~/lyx-devel/ (you
should usually svn update before applying the patches), and a patch file
x.patch, you apply the patch like this:
> cd ~/lyx-devel
> patch -p1 < x.patch
where the -p1 says that one level of the directory hierarchy in the
patch file should be stripped in order to match with the current
location: if you look at one of the above patches, you'll see that there
are separate sections for each file, with a header that looks like this:
Index: lyx-devel/src/Bidi.cpp
===================================================================
--- lyx-devel.orig/src/Bidi.cpp 2007-06-06 10:16:43.000000000 +0200
+++ lyx-devel/src/Bidi.cpp 2007-06-06 10:38:19.000000000 +0200
since the path in the patch starts at lyx-devel/, and since you're
already there, you want the first level to be stripped from the name,
and from the current directory the file to patch should be found using
only "src/Bidi.cpp", without the leading lyx-devel (because you're
already in it). Note that this would also work if your tree is called
xyz rather than lyx-devel --- that's part of the beauty of path-stripping.
So you can just apply the patches one after the other (but the order is
important).
To unapply a patch, just add the -R (reverse) flag. Of course, when
unapplying, the opposite order should be used, i.e., the last patch
applied should be removed first.
Finally, note that if for any reason your tree is different from the
tree on which the patch was created (because you have local
modifications, or just because the tree itself has been updated since
the patch was created), the patch may not apply cleanly. In this case,
the output will say something like "failed to apply Hunk #3", and a
"reject file" is created which tells you what was not applied. This is
the slightly more complicated part if you're new to patches, but
hopefully for now you won't have to deal with it...
Hope this helps!
Dov
