Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Wed, Nov 19, 2008 at 08:59:17PM +0100, Vincent van Ravesteijn wrote:
Dov Feldstern schreef:
1) boundary should not be set to true at a (intra-paragraph) line
break; fixes
this:
abc|\n -> move right -> abc\n (and not: abc\n|
FED FED| FED )
2) boundary should not be set (even if left_font is provided) at pos
== 0;
fixes this:
abc\n -> toggle to RTL -> abc\n (and not: abc\n|
| | )
Hi Dov,
The second example you give here is quite a special case. In this
case, there a three possible locations. At the upper row after \n,
at the lower row in the R-part and at the lower row in the L-part. I
think that this shows that we it is not enough to have a single
boundary member.
I would suggest that we introduce two members: row_boundary and
rtl_boundary. I personally feel that the boundary is a little bit
misused to represent two different boundaries. If we add a second
boundary member, I think that this is solved much more easily, and
the code will be better understandable. Besides, the third patch
you supplied is then no longer needed (I hope).
What do you think of this proposal ?
Sounds good. I was always confused by the different meanings of the
boundary.
+1.
I'm not so sure... I think that if anything, adding another 'state' will make
things even more confused. I agree that the 'boundary' concept is confused, but
I'd like to suggest a way of looking at 'boundary' which makes it less confusing
(at least to me).
I think of 'boundary' purely in functional terms: set it to true in order to
paint cursor *after* the *previous* (logical) position, rather than before the
current position, which is the usual behavior. This way, RTL/LTR, or line
endings, or whatever are totally irrelevant. The only question you should ask
when deciding whether or not to turn on the boundary is: where do I want the
cursor painted? (Obviously, this *does* depend on RTL/LTR, line endings, etc.
--- but not as a 'concept', only as a concrete decision in a concrete situation).
So, I would suggest just changing the name of 'boundary' to reflect this
'functional' point of view, I think that would help to alleviate much of the
confusion. (I'm having trouble coming up with a good name, though...)
This won't make it easier to deal with the special cases, but I don't think that
adding another state would make it easier, either. The special cases are
complex, and so require complex handling. That said, I'm open to looking at
concrete proposals (i.e., code) along the lines you suggested, maybe it *will*
turn out to be easier to follow...
Stefan --- I think you rewrote much of the boundary code last year, do you have
any thoughts on this issue?
Dov
