Stefan Schimanski wrote:
On top of those, we can continue experimenting with the EPM ---
though again, I'm not sure anymore that it's really necessary, and I
also agree somewhat with the issues that Andre' raised...
I think you are right. EPM can come later. We should put in your
patch ASAP. But there is one thing missing I think, have to try first
to be sure: take "abc[ WERBEH]ghi". Can you type space then in front
of the "g"?
Good question --- but it actually seems to be working; it looks like
the space magic kicks in, and switches the space's language. Then the
existing EPM, I guess, removes the new space just typed in. But the
result is that it's working correctly.
Also note that the situation probably wouldn't arise in the first
place, because as soon as 'g' was typed, the space magic would already
have changed the previous space back to LTR.
I expect you can't we at least needs the part of the patch from the
insertChar method which makes this possible. With that addition your
patch has my OK.
I suggest keeping the attached patch at the *bottom* of the stack
now --- I think we all more or less agree with it, and as soon as we
get the OKs, it can be committed (I'd still like to hear from Ran
and Guy and any other Bidi users about it, though). So the attached
is to be applied to a clean svn tree.
With the upper addition and another OK by somebody else, I commit it...
In fact it works, more or less by luck. This is what is happening:
You start with: abc[_WERBEH]|ghi, logically abcHEBREW_|ghi
So by the insertion condition of spaces you are not able to add another
space.
But you code will change the language of the space in front, i.e. you get
abc[WERBEH]_|ghi
Then the insertion condition evaluated to false, hence the new space is
dropped.
Right, this is what I explained above, I think...
Is this what you want? I think adding a condition to your code to only
handle characters other than space would be correct.
Yes, I think it is what we want. The space that was typed at the end of
the Hebrew was meant to separate it from the next word. By switching its
language, we achieve exactly that.
I don't think any other condition is necessary. What's wrong with the
way it's working now?
But now take: abc|[WERBEH_]ghi, logically abc|_HEBREWghi
You cannot type in the space now without the EPM eating it up on the
next key press, altough you should be able to.
No, I'm not sure that you should be able to. Again (and this is true
also for the above case) --- you have to work hard to even create the
situation you're talking about --- it can't happen by just typing,
because when the character after the first space was typed in, the
space's language would already change languages. If the user is working
hard to create problematic situations, then either he wants it that way,
or else he'll have to work hard to get out of it too. There are too many
edge cases, and the fact is, most of the really don't make too much
sense, and there is *no* correct way to deal with it, because it doesn't
make sense, so you don't know *what* the user is trying to do...
The point of the patch is to answer to the fact that it is very common
for people to not pay attention to the order of the language switch and
the spaces, and the patch fixes that.
Again, we can still think about the EPM, I'm not sure whether or not
it's correct and/or necessary. But I don't see why the current patch has
to wait until that issue is worked out. I think its current behavior is
correct, and certainly better then the current situation.
Dov
So, these two things must be fixed before it can go in IMO. I posted
relaxed EPM conditions here somewhere in thread.
Stefan
