Feature request: visual selection history

[romgrk]

Hi,

I have an idea, and I don't really know where to put it, because I have few time to implement by myself now, so I'd like to know if you could keep it? The idea is to implement a visual selection history. It would work like YankRing does, e.g. : gv then successive calls to gv would cycle backward the history.

Use case: sometimes I have a selection I intend to go back to with gv, but meanwhile something else gets visualed (eh no I meant “selected”) so my selection is lost.

I taught about you because this is a good plugin but I think we don't understand what we can do with it yet.

Now that I think there are more ideas to keep:

• Visual zones exchange: mapping so you can do, e.g.:

  select + "ma" (visual mark a), then select + <Plug>VisualZoneExchange, and it would exchange the text currently selected with the visual mark a

• Vim's visual-selection access: e.g.: visual-mark v is mapped to vim's own visual selection
• Background-highlighting of visual marks.
• Also I have this in my rc files:

" Combine with VMarks?
xmap     <silent> <CR>  :call UltiSnips#SaveLastVisualSelection()<CR>gvm'

I don't know if you use ultisnips, but if you don't: this saves the visual selection, and it is used in the next snippet which can contain a ${VISUAL} markup, which is replaced by the value of the visual selection (or by the selection itself, I don't remember)

[iago-lito]

Hi, thanks for dropping a line :)

I see a lot of actual "feature requests" here, some of them are interesting and look doable. Some other just puzzle me. Let's use #11 only for "visual history", shall we? And do not hesitate to open one post per feature so you can take time to explain and justify each other one.

Cycling backwards in history seem not too much difficult to implement IMO. Each mark e.g. a would have its own history so one could cycle backwards typing <a<a<a... This would make the dictionnary a little bit more heavy but size has not been a problem so far. So why not?

I cannot assert being able to look into this right now, but was willing to get back into vimscript by next spring with another plugin (which I think will make it clearer which use case vim-visualMarks intended to address). I'll update the TODO list soon and we'll see what happens ;)