Mario D <egalua <at> gmail.com> writes:
>
>
>
>
>
>
> Perhaps you can repost your example, between pre and /pre tags?
> Paul
>
> Paul, sorry you couldn't see the proper formatting. I repost the formula
with the tags inside the formula, so it should be clear A \frac{1}{2} B + C
\left(1+1\right) D = 2.5 E
>
> I can say that I have exactly the same behavior you describe, in any
place. In fact, I also use the cua bind, plus a bunch of personal bindings
which, however, are not related to moving actions.
>
> It seems to me that there is some consensus about the fact that
moving/selecting could be improved.
>
> Here is what I think. The guidelines should be as follows:
>
>
> Moving:
>
> left/right arrow: moves to the previous/next characterctrl+arrow: moves to
the previous/next wordctrl+home/end: moves to the begging/end of the line
>
> up/down arrow: moves to the previous/next line
>
> Selecting:shitf+arrow: selects from current position to the previous/next
charactershift+ctrl+arrow: selects from current position to the
previous/next wordshift+ctrl+home/end: selects from current position to the
begging/end of the lineshitf+up/down arrow: selects from current position to
the previous/next line
>
> This is actually what really happens when you are in a pure text paragraph.
>
> The problem is how to interpret this inside a formula. I do realize that a
formula has a much more complex structure and syntax than a text paragraph,
yet what happens now is (to me) quite disconnected from what happens inside
a text paragraph and I get very confused when I select inside a formula.
>
> My suggestion is as follows.
>
>
> Let me put a few more tags: A \frac{ AA 1 AB }{ 2 } B + C \left( CA 1 CB
+ CD 1 CE \right) D = 2.5 E
>
> Moving with (right) arrow is consistent: you go from A to AA then to AB or
from C to CA then to CB, CD and CE.
>
>
> Selecting with arrows should be something close to this. That is,
selecting the smallest chunk of code possible.
>
> At present, selecting with arrows has a complete different behavior
depending where you are:- if you are in CA it selects CA-CB (ok)- if you
are in C it selects C-D (why? not ok for me)
Actually, this is the behavior I would expect (and want). The parentheses
are not just characters, they delimit a subenvironment (unofficial term --
I'm not sure what the correct phrasing is) and are a matched pair. If you
replace \left( and \right) with ordinary parentheses, selecting at C gives
you C-CA.
That said, I could live with redefining this if it were done in a logical
manner (see below).
>
>
> Ctrl+arrow and shift+ctrl+arrow are inconsistent:
>
> what happens now is that:- if you are in CA with ctrl+right you go in CE
(ok)- if you are in C with ctrl+right you go in E (not ok)
I agree.
>
>
> and the same when selecting.
>
> What I think it should happen is:- if you are in CA with ctrl+right you go
in CE (ok)- if you are in C with ctrl+right you go in D (a movement that I
cannot perform with any combination)
Again, I agree.
>
> and when selecting:- if you are in CA with shit+ctrl+right you select
CA-CE (ok)- if you are in C with shift+ctrl+right you select C-D (that is,
the same action that at present is performed by shift+right)
>
> Note also that at present Home and ctrl+right arrow behave _exactly_ the
same (and the same for the shifted version): this is a waste of resource in
my opinion and even a bit confusing.
>
I agree here.
> I hope to have explained myself clearly (and not have bored you...)
No, not bored at all.
So, what I would find logical and consistent is the following.
Movement:
left/right arrow move one character (where entering or exiting an inset,
such as going into/out of a subscript, counts as a "character" for movement
purposes);
ctrl-left/right jumps the adjacent "grouping", where "grouping" is the
subtree at the current node if we were to diagram the math inset as a tree;
home/end jumps to the start or end of the entire inset;
ctrl-home/end jumps to the start or end of the buffer (document).
Selection: shift+any navigation combination selects everything from the
current cursor position to where the unshifted key combination would take you.
I don't know if Guillaume's patch would fix this or not. Right now, there do
not seem to be any LyX functions (LFUNs) that relate to this notion of a
"grouping" or syntactic tree node. Internally (meaning in the C++ code),
something like that seems to exist from what Jean-Marc wrote.
There will inevitably be some debate about what the tree structure should
look like. In your example, the root node would be the full expression.
Should the root have three children, the left and right sides of the
equation and the "=" sign? Should it have five children (fraction, "+",
parenthesized group, "=", 2.5)? In the first case, ctrl-right at A would
jump to D; in the second case, it would jump to B, which I would prefer.
I'll leave this to the developers to sort out.
Cheers,
Paul
