Thanks for the helpful reply!
I have reworked the patch (see attachment) based on your input. This one
uses text_char_prev() and is an independent function since this is a
specific operation that don't need repeat/count and probably shouldn't be
added to jumplist.
Marcel
2015-03-24 14:54 GMT-03:00 Marc André Tanner <mat_AT_brain-dump.org>:
> 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 - 20:36:14 CET