On Mon, 8 Dec 2003, Andre Poenitz wrote:
> > While on the subject, something's rotten in Denmark.. mathed, since
> >
> > line-beginning/end
> >
> > behave the same as
> >
> > word-backward/forward
> >
> > as far as I can tell.
>
> Such things could be proven quickly by looking at the source.
Aha! A challenge, well, AFAIC tell they do the same thing, i.e.
case LFUN_END:
case LFUN_WORDRIGHT:
result = mathcursor->end(sel) ? DispatchResult(true, true) :
DispatchResult(false, FINISHED_RIGHT);
break;
and
case LFUN_HOME:
case LFUN_WORDLEFT:
result = mathcursor->home(sel) ? DispatchResult(true, true) :
DispatchResult(true, FINISHED);
break;
> > Both move the cursor to the first or last position
> > of the mathed box, and this seems pointless to me.
>
> Better idea?
Some... in the text below, I'll refer to keyboard shortcuts instead of
LFUNs because it's shorter (for Andre: C-Left = word-backward etc).
Another reason is that this is what the user sees --- I'm looking at
this from the view of a user, and not from how it is implemented.
Now, since HOME === C-Left, and END === C-Right in MathEd, we have room to
change the behaviour of either pair without the user loosing functionality.
I started thinking about what kind of movements I would like to get
for these shortcuts, and unfortunately it's not that obvious... it gets
really complicated when you realize that math-insets corresponds to much
more than simple mathematical expressions. One way to go forward here
would be to start looking at what kind of expressions and movment
operations are most common etc, but that'll take time...
So, if we want a quick "fix" (it's not like anything *really* is broken,
the mathed-interface works quite nice in general), I'd like to suggest
that we try the following:
The behaviour of HOME/END seems ok, so let's keep that and find a new
behaviour for C-Left/Right. My original complaint was that Left/Right
produces small movements, and C-Left/Right too large movements, so I want
something in between.
For C-Left/Right, I would like to try something that "skips sub-insets",
just like S-Left/Right does if the cursor is next to a sub-inset (without
selecting anything of course). I'll try to illustrate what I'd like using
an example based on this equation:
a + ( b + c ) + d
where (b+c) is what I call a sub-inset. The equation was created by typing
"a+", M-m (, "b+c", Right, "+d"
I will use a '|' to indicate the cursor position, so:
a|+ ( b + c ) + d
means that the cursor is just after the first 'a'. I'll use the following
notation to indicate the cursor position before a movement, the
shortcut that is used and the desired position aftewards:
a|+ ( b + c ) + d [Right] a +|( b + c ) + d
Now, pressing C-Right, I'd like this to happen:
a +|( b + c ) + d [C-Right] a + ( b + c )|+ d
where the sub-inset '( b + c)' was skipped over. If there is no sub-inset,
it should go to the end like here:
a + ( b + c )|+ d [C-Right] a + ( b + c ) + d|
Going in the other direction, C-Left should move until it has skipped one
sub-inset or reached the beginning, i.e. like this:
a + ( b + c ) + d| [C-Left] a +|( b + c ) + d
I hope you can understand what I mean with these examples.
/Christian
--
Christian Ridderström http://www.md.kth.se/~chr
