Stefan Schimanski wrote:
But, the fact is that it
works, I've yet to see a problem which is due to the heart of the bidi
algorithm. (Do you think you have found one, now?)
Yes, more or less. We have two bidi algorithms at the moment. One is
inside the Bidi class, the other one in the font setting of Text. They
differ, that's the problem. It gives different behavior with asking the
font of a position whether it is RTL, and with asking the Bidi class.
This happens if you have spaces at the start or beginning of a direction
change.
This situation is still buggy, I suspect very much that the bug is with
the font setting. I'm seeing a bug with font setting, but I'm not able
to reproduce it deterministically, so I haven't reported it yet... (I'll
try to do that now).
Could you point me to where this is, I'll take a look at it?
If you find yourself wanting to change things inside it, then chances
are that's not the right way to go about it; unless you purposely want
to change things from the standard bidi behavior (which I actually
think I may want to do, in order to fix the "GUI-backend bidi
mismatch" --- I'm not sure it's such a great idea, though). But then
that should be done very carefully...
I assume a lot of the deficiencies you describe are due to the fact
that the code is really old, I once started trying to trace something
in there back, and reached the days when a lot of different parts of
LyX were still all in text.C, or whatever it was called then, and
finally gave up. And I suspect that people were hesitant about playing
around with it later, given that they didn't understand it... And when
changes were made, I'm not sure they were always for the better...
My comments mainly were about how things are spread all over the code
and the lack of comments. If there is a member variable bidi, which is
even public, there should be a good reason for it. Moreover it is
changed and accessed from positions so far apart. You remember the bug
where we didn't do the computeTable call on the bidi object for the
right line and got a crash. It's just hard to keep track of all the
places in the code which have to keep a consistent bidi object.
I agree with everything you say here. I was just trying to explain why
it was probably like that...
All that said, I must reiterate again: I don't know this code, either...
Didn't want to critisize you, sorry it sounded like that.
It didn't, you don't have to apologize :) . As I said, I have absolutely
nothing to do with this code, I can't take the blame, nor the credit
(and I actually give it a lot of the latter --- though not the aspect of
it that you're complaining about, correctly...) ;)
Let's improve the mentioned problems for 1.6.
Okay, but very very carefully. That's mainly what I got worked up about
--- I'm afraid of touching things that work, unless there's a very good
reason to. I'm not yet convinced that there is. Especially if we don't
understand exactly what we want to do, and I find it hard to believe
that someone who doesn't use Bidi would understand all the nuances; as
you can see on the list here, I don't think that even those of us who do
read bidi understand (or agree about) it all ;)
Stefan
