Howdy,

Posting a copy of my new feature request #438563 for discussion:


Keyboard selection in mathed using Shift-movement should act as
similarly as possible to normal movement inside mathed. Specifically,
the following should be supported:
* S-<home> and S-<end> (with the nested behavior of <home>,<end>)
* S-C-<left> and S-C-<right>
and possibly others.

A related issue: when holding down Shift and pressing <right> until the
cursor leaves the math inset, pressing <left> should undo the last
<right>. Typical scenario: you want to select to to the end of an
equation (or nearly so), but overshoot. Currently (1.2.0cvs), the above
sequence causes a zero-sized selection to the right of the inset, with
no way to recover the original selection. The same happens when you
overshoot the end of a parenthesis and try to go back.  In short, I
don't like the following part of MathCursor::Right():
--------------------------------------------------
                result = array().next(cursor_);
                if (!result && pop()) {
                        anchor_ = cursor_;
                        result = array().next(cursor_);
                }
--------------------------------------------------

I propose the following semantics: 
When Shift-movement selection is initiated in mathed, record the anchor
(starting position) and *keep it fixed* as long as the Shift key is
down. Let the cursor move normally using all the usual navigation keys,
except for the following: each inset that is not an ancestor of the one
where the anchor resides should be treated atomically, i.e., like a
single character (this is the current behavior). This maintains the
invariant that the inset where the cursor resides is an
ancestor-or-same-as of the inset where the anchor resides. At any
moment, the current selection is defined as follows:
* If the cursor is in the same inset as the anchor, you know what to do.
* Otherwise, the selection is defined at the inset where the cursor
resides, and contains everything from the cursor to the (child) inset
which contains the anchor, inclusive.

Does this sound reasonable?

This also seems like the right behavior in general wherever nesting is
involved, such as tabulars.

By the way, in current 1.2.0cvs: when you start selection from within a
math inset inside a tabular you can exit the tabular cell during
selection (using mathed's selection semantics), but if you start it from
normal text inside a cell you can't exit the cell.

And finally: Should mouse selection should have the same anchor&cursor
semantics as keyboard semantics? Currently it doesnt. Example: 
type    C-m x M-m ( y       to get      x([])y
then    <left> S-<left>     to select the parenthesis
It's impossible to get the same selection using the mouse.


  Regards,
    Eran Tromer

Reply via email to