Dov Feldstern wrote:
Dov Feldstern wrote:
Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the
user will learn to press END (end of line) to move it to continue
typing. It is logical, (not in the "logical" direction sense),
expected and easily adapted to by the user, as there are no surprises
there.
It doesn't seem logical at all to me, though I guess I user could get
used to it. But I'm glad you've dropped this idea... ;)
Abdel's idea is even better. I second it.
When writing, lyx will assume you want to jump to the end of line,
but when editing, it will assume you don't!!
How does one differentiate between "writing" and "editing"? By whether
I'm at the end of a paragraph or not?
This is what (I think) I said somewhere in this thread: in order to
get the behavior to be more intuitive, you have to start using
heuristics which try to figure out "what did the user mean this
time?". And the nature of heuristics is that they are sometimes right,
sometimes wrong; and they certainly make the code more complicated. So
yes, it's a possibility, but we should consider carefully if the
heuristics are correct, and whether we want to implement them in each
case...
Also, heuristics make the application behave differently in different
situations (that's there purpose!) --- which means that the application
is less predictable unless the user exactly understands how the
heuristic works...
Therefore, I would try to stay away from heuristics if possible, unless
they are absolutely intuitive (and the heuristic that I provided above,
I think, is not so intuitive).
And, the fact is, I think that in this specific case, LyX's behavior is
perfectly logical and intuitive, and almost always what I want it to be.
If you think otherwise, please explain again exactly what the specific
situation is, how you got to that situation, and what you think LyX
*should* do in that case...
Dov,
did you direct me to here in response to bug 3011?
Well, anyway, your fix for 3011 is working. I have version 18791.
Miki
I have found something very strange!!! a feature? Try this:
I changed my document to Hebrew, so that English gets marked foreign.
Type a line (starting with RTL) such as LTR LTR LTR RTL RTL RTL
Now, in the border between LTR and RTL, to the LEFT of the space, it
would seem that this is one cursor position, but with the mouse I can
actually hit TWO points there (still to the left of the space but to the
right of the English writing): one position continues the Hebrew, and
the other position continues the English (the cursor is underlined).
Now, it would seem that IF the arrow keys could move through these two
states (in our future visual mode, where the cursor will move without
jumping to the beginning of English, but through the end of it) it would
solve our conflict, as the cursor will tell us what is going to happen
while editing. When you come from RTL, it will first be RTL, another <-
will move you to LTR (the end of it), and other <- will move you
backwards in the English, and while typing you would keep moving to the
end of the line when pressing F12 for continuous typing like you want
(which makes more sense to me now). That is OK by me, and it will
actually be very good I think.
What do you think?
Currently, the arrow keys miss the "continue English writing" position
since the behavior is logical, and the cursor goes directly to (ONE
AFTER) the beginning of the English in logical mode. I still don't
understand why it jumps to one after the beginning of the foreign part.
It could have easily have jumped to the beginning of English.
Miki
