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 <m...@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 > >
0001-Implement-o-in-visual-mode-go-to-other-end-of-select.patch
Description: Binary data