Re: [dev] [vis][PATCH] Implement 'o' in visual mode: go to other end of selection.

From: Marc André Tanner <mat_AT_brain-dump.org>
Date: Tue, 24 Mar 2015 18:54:12 +0100

On Tue, Mar 24, 2015 at 12:22:14PM -0300, Marcel Rodrigues wrote:
> Hello,
>
> This feature makes it easier to extend the selection in both directions.
> The behavior is the same as in vim: in visual mode, the 'o' key toggles the
> cursor position between the two ends (handles) of the selection range.
>
> The attached patch seems to work as expected

Thanks, I will apply it later!

Did you also test it with some multi byte characters? I think your
sel.end-1 should be replaced by text_char_prev(vis->win->text, sel.end).

And yes the whole selection handling should be cleaned up. At the moment
it is internally (in window.c) represented as an interval [start, end)
that is the selection end is denoted by the start of the last selected
character. However window_selection_get returns it as [start, end],
notice the text_char_next call. To make things worse window_selection_set
currently expects the former format. That is

 window_selection_set(window_selection_get(...))

will actually extend the selection. Cleanup patches welcome!

Other things to consider when overhauling the selection handling

 - support for multiple selections (maybe a selection should not only
   have a start and an end point, but also an anchor?)

 - visual block mode, which might or might not be best represented
   as a set of individual selections ...

> but I'm not sure it's the
> correct way to implement this (I'm still a bit confused about the different
> ways that movements are implemented in vis).

The way you choose via the moves[] array with a corresponding enum
value is for movements which can be used in conjunction with an operator
and should thus be repeatable. Other reasons to do it this way are
support for a count argument as in 3j, or registration in the jump
list.

The other way to do it is via an "independent" function which simply
internally calls window_cursor_to. This should be used if nothing
of the previously mentioned (repeatable, count argument, jumplist ...)
is necessary.

Your particular case might be better suited for the second case?

That was the original idea, however in practice it is not strictly
followed. For example navigation of the jumplist/changelist is
done via the second option which means it can't be prefixed with
a count.

Thanks!

-- 
 Marc André Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
Received on Tue Mar 24 2015 - 18:54:12 CET

This archive was generated by hypermail 2.3.0 : Tue Mar 24 2015 - 19:00:10 CET