Improved move_cursor functionality

[kylechui]

I'm thinking of adding "sticky" to the move_cursor functionality in #334; if anybody has ideas/suggestions/objections they would like to share, feel free to do so here.

The current functionality only really supports "begin" and false, which move the cursor to the beginning of the selection and keep the cursor stationary, respectively. The idea is that "sticky" keeps the cursor "stuck" to whatever character the cursor was on before the surround action. See the unit tests in #334 for an idea of how exactly this would work.

One nice use case for this is dot-repeating with a sticky cursor, as one can do ysiw]. to surround a word with double brackets, whereas the old behavior would do something like hello → [[]hello] (since the dot-repeat would surround the open square bracket).

Please react to show interest in this feature!

EDIT: Functionality seems pretty complete in #334; might merge it soon-ish 🤔

[bew]

I'm interested in the sticky behavior at least to try it!

[kylechui]

I would agree that it's more interesting to me, but unfortunately seems to be much harder to code up haha

[bew]

Extmarks can't auto-help you with that?
Since afaik extmarks are updated to keep their relative position when the buffer gets updates around it (in all case?)

[kylechui]

Ah you might be right! I remember dealing with them a while ago because the API was deleting them, but hopefully in this use case things will work out nicely.

[kylechui]

Turns out with extmarks the implementation becomes ridiculously easy, thanks for the callout!

[ggandor]

I don't see any use case for end. What's the motivation?

Putting aside the question of implementation and whether it's worth the complexity, sticky would be nice indeed, especially for dot-repeats. However, once implemented (if implemented), is there any reason to keep false?

[kylechui]

Hmm I could've sworn that someone asked for the feature at some point, but I can't seem to find it anymore. I think that sticky is definitely more important/useful to have, so perhaps I'll start with that and if anyone wants end functionality then that can be added later. As for false, I think that since it's already defined (and it's low-cost to maintain), I'll keep it around, since I imagine at least one person out there would be mad if I suddenly removed it for no reason.

[ggandor]

As for false, I think that since it's already defined (and it's low-cost to maintain), I'll keep it around

It would make more sense to improve false then (to behave in a "sticky" way), instead of adding another option. I don't think anyone would prefer the current false behavior over sticky, would they?

[mtrajano]

One other thing I was thinking related to cursor_position was the ability to set a custom cursor position after the surround.

One example I thought of recently was in the case markdown or other similar markup languages if you have a custom surround to insert a link such as:

["l"] = { -- for link
    add = { "()[", "]" },
}

And want the cursor to end up in the parenthesis, ex. (*)[some text].

Thoughts on this?

[mtrajano]

I was thinking another example could be a function surround and having the cursor be placed after the function keyword in order to define a name.

But... actually thinking a little more about this, they are technically not "valid" surrounds, they're missing the "text" part of it which can probably be better handled with the config.get_input helper (which is actually what I ended up doing for the example above:

local result = config.get_input('Enter link: ')
return { { '{' .. result .. '}[' }, { ']' } }

Not sure if there's a valid use case for the custom cursor placement but just a thought

[kylechui]

I think the custom cursor placement maybe could be a solution to #145, but I would need to do some more thinking. I really want to avoid a convoluted solution, e.g. having two funcs for post-surround cursor position, and mode. One thing one could do is to manually map csf to something like <Plug>(nvim-surround-change)f(i or something like that (not tested). The gist is to just manually relocate the cursor after the desired motion, rather than have it be a built-in feature.

[bennypowers]

this would be nice for cases like emmet abbreviation, in which case we'd like to jump to completion stops

t = {
  add = add_function_for_emmet_abbreviation,
  ---@type 'begin'|'sticky'|(function(): nil|'begin'|'sticky')
  move_cursor = function()
    -- function which either 
    -- 1. moves the cursor for you
    -- 2. returns a (string) move cursor type
    -- 3. returns nil, thus falling back to globally configured behaviour
  end,