Expand key and Visual Mode selection

[IndianBoy42]

This branch is based on #81 so that should be merged first.

• expand_key
  • ISwap, ISwapWith
  • ISwapNodeWith
  • ISwapNode already can select arbitrary nesting
• visual mode select (all the at_cursor functions need to handle visual mode and ranges)
  • make it work from cmdline (hitting : ends the visual selection)

Address #79

[IndianBoy42]

ISwapWith visual mode behaviour is obvious to me. The selection range should be equal to or subset of a child node of the list. The selection is serving to choose the child node, the way the cursor does in normal mode. Then the normal mode behaviour is equivalent to visual mode behaviour with a single width selection.

ISwap visual mode behaviour I think has two choices

1. the selection range is the user trying to define one of the child nodes, even though the selection is not actually the node that will be swapped. so it works the same as ISwapWith
2. the selection range is the user trying to define the list node, so if there is a list node with range equal to or smaller than the selection (picking the largest one), we should use that, and the labels will be 'inside' the selection range. and if there is no list node contained within the selection... give up or fallback to option 1?

Note that in the second case the normal mode behaviour is not equivalent to visual mode behaviour with a single width selection. but intuitively this seems to make more sense. One argument against the second is that its more keystrokes when trying to deal with lists nested with the same kind of braces: for { {...}, {...}, {...} } with the cursor in the most nested list, doing vib<cmd>ISwap<cr> or <cmd>ISwap<cr> is the same, you would need vibib<cmd>ISwap<cr> to select and swap in the outer list.

How do you think visual mode selection should work?

[mizlan]

What if cursor was just a special case of range with length 1, for purposes of calculating things?

[IndianBoy42]

Yeah that would be the first solution. I'm just wondering if that's really the best way in terms of utility or intuitive behavior. This branch is in a working state so you can try it out. I've implemented both behaviors controlled by a config variable

[IndianBoy42]

Have you got the chance to try this out?

[mizlan]

not yet... been busy, i will definitely try it by EOD Wednesday

[mizlan]

Flash-confirm highlighting is broken on a case like this:

{'a', 'bcdefg'}

The 'a' is supposed to be highlighted first but something happens. I can look into it.

By the way, I am certain this is not related to this PR, just something I've noticed.

[IndianBoy42]

Yeah I think its actually related to the refactor of swap_ranges_and_return_new_ranges that I did in my last PR

[IndianBoy42]

New idea implemented, not sure how visually clear it is, but basically it labels the parents of the node, hitting one of those labels relabels which nodes will be swapped (basically the same as hitting expand/shrink a few times). Now ISwapNodeWith is kind of similar but mostly better than ISwapNode (2 keypresses for any 2 nodes, 1 keypress if you started it at the correct nesting level). I even think if ISwapNodeWith was made to use the list query to find the initial list, it would be strictly better than ISwapWith (1 key for the most common case, able to swap almost any 2 nodes with 2 keys).

EDIT: that second part is done, I feel like ISwapNodeWith should be the default, its fast and flexible