Miki Dovrat wrote:
Hi,
I already replied Stefan off list, but I will post this again so anyone can
comment.
The brain (at least mine) does not like movement to the opposite side. When
you press the left arrow, you expect the cursor to move to the left. Try
riding a bike with the hands crossed, wear a helmet!!!
So I think the visual movement is the most convenient and intuitive.
Microsoft Word is an example of how NOT to do it. It does not change the RTL
or LTR mode except by an explicit request by the user (ALT-SHIFT), and even
as you cruise into a RTL part, and you want to add a letter, if you were
writing English before, the added letter will be English. And the cursor
movement is to the opposite side (it jumps to the end of the RTL, and goes
backwards in opposite of the arrow key).
As far as getting used to logical movement, you can get used to anything,
but it is easier to get used to good things. Nobody complains about Word
since the Israeli market is small and big companies always do us (the Hebrew
users) a "favor" by thinking about us at all, so we accept whatever is given
us.
I would like lyx to be a little smarter, and to change its RTL or LTR mode
by itself as you move across already written text. When you point at a word,
the most COMMON intention is to add letter or fix spelling or continue
writing, so lyx should already put you in the right language (it doesn't do
so now). If you want the opposite language, I think you should ask for it
explicitly once you are in place.
Thanks for the interest.
Miki
"Stefan Schimanski" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
Hi all!
Instead of replying individually to all the messages on this subject,
I'll try to sum up my responses here.
First of all, just for the record --- as Miki pointed out, I *am* an RTL
user ;) . I also have a lot of experience with Bidi editing in LyX. It's
just that this issue is particularly thorny --- because what I consider
to be the correct solution (the one that does not impose limits on the
user) is 99.9% of the time *not* what the user meant (I'll explain below).
---------------------------------
But first: a side issue which has been raised in this thread is that of
"visual movement".
A feature request for this already appears in bugzilla
(http://bugzilla.lyx.org/show_bug.cgi?id=3577). Note, however, that this
should *not* replace logical mode, but rather be an option for the user
to choose which she prefers.
Regarding implementation of visual mode:
*) I agree 100% with Miki above about how it should work: the current
language should be determined by the current font, *not* by remembering
what the last font was.
*) The basic idea for implementing visual mode is dead simple: pressing
RIGHT in LTR paragraphs (LEFT in RTL) should move to position
vis2log(log2vis(pos)+1), and the opposite is with -1. (vis2log and
log2vis are in Bidi.cpp. In this case, Stefan, I think you're going to
*have* to use them, I don't see any way around it).
But there are a lot of details to work out: there may still be issues of
boundary, I'm not sure; there also may be some logic needed in order to
make the transitions between paragraphs behave correctly (e.g., I'm in
an LTR paragraph moving RIGHT. When I reach the end of the paragraph,
pressing RIGHT again should move me to the *end* of the first line in
the next paragraph if it's RTL. I'm not sure if this is already covered
by vis2log or not.); math insets would have to be adjusted separately, I
think. But basically that's it. But I think it'll take a little work to
work out the kinks.
I'm attaching a patch which just demonstrates the feasibility of this
approach. It crashes all over (or shall I say: left and right?) --- I
don't deal with any edge (no pun intended) case whatever. But if you
type in some mixed English--Hebrew text on a single line, with the mouse
move the cursor somewhere that's not at an edge, then you can move
around visually as long as you stay away from the edge. But the problem,
of course, is working out all the details...
In the meantime, we have tried to make cursor movement in bidi documents
behave a little more predictably:
In an LTR paragraph, RIGHT moves forward (logically) --- both in RTL and
in LTR texts (so in RTL it's moving opposite to the arrow, yes) --- and
LEFT backwards. And the reverse for RTL paragraphs. Insets (e.g.,
footnote) within a paragraph also follow this rule: in an RTL inset
inside an LTR paragraph, arrow direction will be "backwards". This was
implemented in order to avoid the cursor getting "stuck" between RTL and
LTR insets, as it used to up until now.
Two other differences which provide the user with some visual feedback
which make typing bidi a little easier:
1) The language of spaces is now marked; so if something funny is
happening with spaces in bidi, it's a little easier to figure out why.
2) As in previous versions of LyX, the cursor will now change shape in
RTL text (or in LTR text in an RTL document), so it's easier to see
which direction you're currently typing in.
So that's regarding visual movement.
------------------------------------
Back to RTL spaces:
The problem is this: almost always, the user just wanted a space between
the previous word (which happened to be, say English) and the next one
(which happens to be Hebrew), but by mistake pressed F12 before space
and not first space and only then F12. In fact, I can't think of *any*
case in which it is important to the user for it to be any other way.
However, I still think that it is more correct for us to pay attention
to the language of spaces. If we don't, then there are things which I
*would* like to be able to typeset, but won't be able to (see example
below).
After thinking about this a lot, this is the solution I would like to
see (I think it's similar to Georg's views, if I understood him correctly):
Spaces will behave as follows, by default:
*) While typing in, a space between words in different languages should
*always* have the language of the paragraph. This means that a space's
language may be changed as I start typing in the next word, and then
would also "jump". But I think that's almost *always* what the user
wants. Implementing this may not be trivial, though, because while
typing in, you have to look *two* positions back: is the previous
position a space, and if so --- what is the language of the position
before it? (and should this also work forward? perhaps it's not necessary)
*) Otherwise (i.e., a space between words in the same language) should
keep the language in which it was originally typed in.
However, after a space has been typed in, regardless of its position,
the user may still select it and switch its language, and that will be
kept (unless the user types in next to it again...). So this still
leaves the user full flexibility, but *usually* does the right thing.
Generating latex should continue as it is now --- in other words, always
pay explicit attention to the language of a space. The GUI should behave
as it did with Stefan's patch rtlspaces (the very simple version, which
uses the space's language rather than treating it as neutral). Of
course, it's also up to the GUI to implement the "default behavior"
specified above, as things are being typed in.
One last issue: EPM/DEPM: there should *not* be any special treatment
for this. It should not be possible to type in two logically consecutive
spaces, regardless of their language. This is also simpler to implement,
and also more correct IMO. In the situation that you asked about, Stefan:
abc[FED ] ghi
if the user wants a space between c and F, the correct way to do it is
for the user to change the language of the space before D to English. No
need to create boundaries and fake spaces here.
-------------------------------------------------
Example for something which can't be typeset if the language of spaces
is ignored:
I want to say "The RDBMS PostgreSQL" in Hebrew. "The" in Hebrew is the
letter "heh". I'd type it in this way: In Hebrew, the letter "heh"
followed by a hyphen; F12 (switch language), and type the English word
"RDBMS". F12, then a *hebrew* space, F12 and then the English
"PostgreSQL". Visually, with H representing the "heh", it should look
like this:
"PostgreSQL RDBMS-H"
However, if the space is neutral, we get this behavior: since the space
is between two LTR words, it'll be treated as LTR, too, and then we'll
get, visually:
"RDBMS PostgreSQL-H"
Which is not what I want. (Though whether what I want is correct or not
is arguable, but *I* want it that way anyway; and I'm a user, so I
should be able to do it.)
BTW, if you try this in LyX 1.3.X (don't know about 1.4) the LaTeX
output will be correct, but the GUI won't be. So some of these problems
existed way back then, already...
Hope someone reads this through!
Dov
Index: lyx-devel/src/Text2.cpp
===================================================================
--- lyx-devel.orig/src/Text2.cpp 2007-06-06 02:13:06.000000000 +0300
+++ lyx-devel/src/Text2.cpp 2007-06-06 02:20:03.000000000 +0300
@@ -985,6 +985,7 @@
{
// Tell BufferView to test for FitCursor in any case!
cur.updateFlags(Update::FitCursor);
+ return setCursor(cur, cur.pit(), bidi.vis2log(bidi.log2vis(cur.pos()) -
1), true, false);
// not at paragraph start?
if (cur.pos() > 0) {
@@ -1027,6 +1028,7 @@
{
// Tell BufferView to test for FitCursor in any case!
cur.updateFlags(Update::FitCursor);
+ return setCursor(cur, cur.pit(), bidi.vis2log(bidi.log2vis(cur.pos()) +
1), true, false);
// not at paragraph end?
if (cur.pos() != cur.lastpos()) {
