Re: [Texmacs-dev] Logical cursor movement

[David Allouche]

On Fri, Aug 23, 2002 at 02:43:17PM +0200, Joris van der Hoeven wrote:

In the series of laaaaaaate replies (and there is more to come)...
 
> > When one goes to the next structure we may suppose he/she wants to make
> > some modifications. Thus, a further (smaller) move is needed or else a
> > delete backwards(if in the end) or forwards (if in the beginning). I
> > don't see which is more useful. I'm personally used to backspace so I
> > would favor moving to the end, but that's not a big reason to choose (it
> > doesn't even convince me).
> 
> I also prefer moving to the end; this is already the default behaviour
> in computer algebra sessions. However, how would it be possible for
> someone to quickly move to the start using the same keys,
> like C-right C-left might accomplish?
> 
> > I think it is essential to go directly to the next argument instead of
> > passing through the end of the current. At least I'm sure of that.
> 
> OK, but again, what should be provide for people who want to
> move to the start of the next argument?

I can think of a scheme which I find elegant and allow easy access to
both ends.

  -- move right (resp. left) move the end (resp. beginning) of the
     next (resp. previous) cell.

  -- subsequent moves right (resp. left) keep on moving in the same way

  -- first move left (resp. right) after one (or several) moves in the
     opposite direction moves to the beginning (resp. end) of the
     current cell.

Yet I do not think that is really natural.

What I think is the most ergonomic solution is "right (resp. left)
moves to start (resp. end) of next (resp. previous) cell. The point
here is this will place the caret nearer to its previous position,
that should reduce the required eye motion.

That could be extended to allow relatively easy access to both end by
making "move right" move the end of the cell when the current cell is
the last cell of the table (resp. with move left to the start of the
first cell of the table). In non-end cells, the other end of the cell
can be attained by moving on one more cell, and then moving back.


> > I think we should find a way to signal with a very fast key combination,
> > to which structure will apply the next operation. Imagine for a moment
> > that you could enter a number without printing it (as a modifier).
> > 
> > [0 ->] would move one structure next inside the current level
> > [2 backspace] would delete backwards the previous structure inside the
> > second enclosing level.
> > [1 insertmatrix] would insert a matrix inside the enclosing level, not
> > at the current cursor position.
> > [2 hat] when you're inside a fraction which is inside an integral would
> > put a hat over the whole integral. 
> 
> I am against this, because the use of "0", "1" and "2" will not be clear
> for users. I am rather in favour of using the outward selection mechanism
> to select the environment on which you wish to perform one or several 
> operations and then make certain movements relative to this environment.

I think Alvaro was not really considering using digits as modifiers...
he reads "Imagine for a moment that you could enter a number without
printing it (as a modifier)".

But I like the idea of motion relative to the last outward-selected
structure... If only there was an easy way to revert the selection as
it was before the last ctrl-space (and previous ones, too).


> > I think it would be interesting to imagine such a general way to say in
> > wich position of the tree you want to operate. Then, shortcuts could be
> > provided to the movement operations for the current and first enclosing
> > level.
> 
> There is another problem with all this, because certain enclosing levels
> are more important than others. For instance, imagine that you have a big
> matrix with complicated formulas in it. You are inside a complex formula
> and you want to move to the next cell of the matrix at the right.
> Do we want some special kind of keystroke for this?
> Maybe something like "E-t right"?

Seems right to me.

 
> > > Did I forget something? One might also wish to have bindings
> > > to move the previous and next words and potentially mix that
> > > with the structured movements. I am not sure whether this would
> > > be really handy though.

I think we should not use word motion inside table... but otherwise it
does make sense to bind ctrl-left/right to word motion and, Alt or
Meta left/right to structured motion.

> > levels of structure in text: word, sentence (some heuristics needed),
> > paragraph, section body... whatever. I don't know how this mixes with
> > the trees in the implementation, but it could be interesting if we made
> > a better/more comprehensive list.

By the way, the current definition of word motion in TeXmacs is
stupid. Punctuations and hyphens are considered equal to letters,
while they should rightfully be considered word delimiters.

> > I am not sure if word is sufficiently meaningful for structured actions.
> > But it is useful. The same with variable, below.
> > 
> > in math: variable, function (in roman), fraction, visually grouped
> > symbols (via parentheses or braces), invisible groups (terms, macros,
> > user defined groups, large operators as containers --sums,
> > integrals...--), row in eqnarray, whole eqnarray, set of eqnarrays
> > pertaining to the same argument and linked although with interspersed
> > (explanatory) texts...
> 
> Yes, I also rethought about this, especially small or large parentheses
> and big operators; maybe this should really be structured primitives
> after all.

I do not care about the underlying implementation (that's the actual
structure of the document tree) but it think it does make sense for
big delimiters and operators use more structure... probably something
like:

  (bigdel "(" "a+b" ")")        and     (bigop "<int>" "a+b da")

That would allow maximum flexibility with simple implementation, would
fix existing problems with big operators, and make the selection
behave in a structurally consistent way.

However, one may sometime NOT WANT the selection to behave in a
structurally consistent way, for example when copy pasting large chunk
of existing formulas in a hurry while typing down a course.

Moreover we do not want these structure, especially the bigdel
structures, to change cursor motion. The current cursor motion
behaviour in formulas is easy and (mostly) natural. Moving past a big
delimiter of big operator ought to be only ONE step. Not several as it
can happen if we give bigdel the same behaviour as regular macros
w.r.t. cursor motion.

> The real problem is that we need a clean classification of
> all types of structured movements that we might need.
> We can next analyze them and throw out the ones which
> are likely to be used very little. The residue should be
> what we want.

Someone volunteers?

-- 
                          -
David Allouche            |  GNU TeXmacs -- Writing is a pleasure
Free software engineer    |    Home page -- http://www.texmacs.org
    http://ddaa.net       |    Resources -- http://alqua.com/tmresources
    address@hidden    |    Dev's IRC -- #texmacs irc.openprojects.net
GNU TeXmacs developper    |        TeXmacs is NOT a LaTeX front-end
    address@hidden  |        and is unrelated to emacs.
                          -