Restore cursor position about comment.nvim

[astier]

I actually think that a user would expect such behavior. The only reason I see why users wouldn't expect it is because they are already used and conditioned to this after years of using comment-plugins which move the cursor-position.

I also think making this behavior default would be more consistent with how gcc in Comment.nvim currently behaves. gcc also doesn't move the cursor position to the beginning of the line whereas vim-commentary does move the cursor to the beginning of the line.

It's your decision after all but I personally wouldn't be to afraid to break from old norms if the new one is better.

Counter question. Are there reasons to move the cursor? It always felt arbitrary and disruptive to me.

[numToStr]

Thanks, @jandamm for the explanation. Surely marks might be the way around this. But

• Marks API neovim/neovim#15346 recently got merged, thus only available in nightly. (I'll hate doing this the VimL way)
• Currently marks disappear when doing lines comments #24. This might be because of nvim_buf_set_lines which might be resetting everything like marks, ext-marks. Although nvim_buf_set_text might be the solution but IDK for sure.

---

Considering the above, I think fixing marks should be the priority. Thoughts??

[astier]

@jandamm I wrote it a little bit confusing but I didn't mean that you use marks. I like your solution. I was responding to @numToStr because he suggested to use marks internally.

[numToStr]

Thanks for putting up your point. I had considered restoring cursor position as I also want this behaviour. But it might be subjective and other user might not expect this. Thoughts?

[numToStr]

It's your decision after all but I personally wouldn't be to afraid to break from old norms if the new one is better.

Same feelings 😂. As I said earlier, I also want this behaviour. So, I'll implement this sooner or later.

Are there reasons to move the cursor? It always felt arbitrary and disruptive to me.

IDK this might be a vim thingy. I didn't added any special cursor handling as of now. And most of the mappings like gcc gc10j doesn't move the cursor position.

[numToStr]

I tried and I failed 😢 . I don't know what is happening but I am not able to get the old cursor position. So, when the associated callback with keybind gets executed I am getting the same cursor position before and after commenting. It's somewhat same as when pressing yip, the cursor seems to move to the start of the first line.

[astier]

I guess the solution would be to store the position in a variable before commenting and than moving the cursor back to the position in the variable after commenting.

[numToStr]

So, when the associated callback with keybind gets executed I am getting the same cursor position before and after commenting.

You can't 🙁. Technically you can but the both values are same. I suspect this is beacuse of g@ operatore-pending mode.

[astier]

So, when the associated callback with keybind gets executed I am getting the same cursor position before and after commenting. [...] both values are the same.

What do you mean you get the same cursor position? Which both values?

So I was thinking about storing position in variable with :h getcurpos() and moving the cursor with :h cursor() I am not sure what could go wrong there.

[numToStr]

Try getting cursor position inside pre and post hooks and press gcip. That should clear things up a bit.

[numToStr]

@astier This is what I was talking about, the cursor position before and after comment being the same.

2021-10-16.11-23-29.mp4

[jandamm]

This observation should be true.
The opfunc is called with the current selection applied. So after the cursor has changed.
Only way I'd see is to use a mark.
For example prefix i<ESC> to set the mark and then after the opfunc jump to mark ..

[astier]

I just checked it for myself and understand now what you mean @numToStr If at

Comment.nvim/lua/Comment/comment.lua

Line 169 in a86384d

Op.opfunc(cfg, vmode, U.cmode.toggle, U.ctype.line, U.cmotion._)

the cursor-position is already moved before the function is called because as @jandamm said at this point the selection has already be done and the cursor moved than the position has to be stored before the selection is done.

I just tried @jandamm PR and it works for me. It solves it more or less how I imagined it. I am not sure if using marks is a good solution. Wouldn't this potentially pollute/overwrite the user-marks?

[jandamm]

My solution does not use marks after all. It stores the current position as buffer variable before the operator is applied.
Afterwards it moves to the position and removes the variable.
So unless some other plugin uses b:comment_pos there should be any collision.

[numToStr]

I am not sure if using marks is a good solution. Wouldn't this potentially pollute/overwrite the user marks?

Yup, this is surely a concern.

---

@jandamm I liked your approach though. I'll keep the rest of the talking on the PR ✌🏻.