Re: [Texmacs-dev] Logical cursor movement

[Joris van der Hoeven]

> Statistically if one wanted to reduce keystrokes one could search for a
> definition of "middle of the next argument" and go there. But this is
> confusing for the user. It doesn't seem realistic to me but maybe
> someone will find the use of it.

This seems confusing.

> 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 also think there has to be a structured cursor motion to get out of a
> previous level with only one keystroke.

Yes, I was reserving C-pageup (move out at the start) and
C-pagedown (move out at the end) for this.

> Hopefully the
> visual boxing of nested structures will be very clueful here, esp. if a
> distinguishing colour is attached to the first enclosing level.

Yes, I have also been thinking about this; maybe a darker blue?

> So you would have operations for at least the current and the previous
> level. I don't know if a generalization of this mechanism would be
> useful, but there's food for thought with it, because you might be
> inside a very complicated structure and move very fast if you're able to
> do structured movement within the enclosing structure of the enclosing
> structure.

In order to do so, we would need something to quickly enter
a structure again, but it is not clear where to enter it.

> To summarize this mess (I'm not especially inspired today):
> 
> 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 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"?

> > 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.
> 
> 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.
> 
> 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.

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.