Hi, Dov,
I don't understand why you would need to keep the logical behavior. In my opinion it is just bad, but we have all gotten used to it so it feels familiar. I will join the devel thread as Stefan requested. Miki "Dov Feldstern" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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()) { >
