Re: [Texmacs-dev] Logical cursor movement

[Álvaro Tejero Cantero]

Hi, 

> 
> 1. Always go to the end
> 
>    ........  ...|....  ........  ........
>    ........  ........  .......|  ........
>    ........  ........  ........  .......|
> 
>    ........  ...|....  ........  ........
>    .......|  ........  ........  ........
> 
> 
> 2. To the end when moving right and start when moving left
> 
>    ........  ...|....  ........  ........
>    ........  ........  .......|  ........
>    ........  ........  ........  .......|
> 
>    ........  ...|....  ........  ........
>    |.......  ........  ........  ........
> 
> 
> 3. Inverted 2
> 
>    ........  ...|....  ........  ........
>    ........  ........  |.......  ........
>    ........  ........  ........  |.......
>    ........  ........  ........  .......| [optional]
> 
>    ........  ...|....  ........  ........
>    .......|  ........  ........  ........
>    |.......  ........  ........  ........ [optional]
> 
> 
> 4. Other variant
> 
>    ........  ...|....  ........  ........
>    ........  .......|  ........  ........
>    ........  ........  .......|  ........
>    ........  ........  ........  .......|
> 
>    ........  ...|....  ........  ........
>    ........  |.......  ........  ........
>    |.......  ........  ........  ........
> 
> 
> Etc. What would you prefer.

My biggest use case is when the next structure is empty. However, some
reflections come next.

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.

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

In addition we have the optionals/end in current debate. I'm not much
for any of them, although I have problems to think of an use case. How
would optionals and 'end in current' managed if not with these
structured movements?. 

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.

I also think there has to be a structured cursor motion to get out of a
previous level with only one keystroke. For example, [next next next]
would take you to the end of the row in a matrix, and [next] again to
the first column in the next row, but there should be a way to get out
at once of the enclosing level (the matrix structure). Hopefully the
visual boxing of nested structures will be very clueful here, esp. if a
distinguishing colour is attached to the first enclosing level.

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.

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

Well, this might be crap, 

regards, álvaro.
-- 
álvaro.tejero.cantero
alqua.com, la red en estudio
"La perfection est atteinte non quand il ne reste rien à
ajouter, mais quand il ne reste rien à enlever"
Saint-Exupéry.