Marks are moved by `gcO`

[PowerUser64]

Incorrect (current) behavior

When running gcO on a line that has a mark on it, the mark will be moved to the line the comment is being placed on.

Example:

1. Put this code in a .cpp file (to set comment string automatically) and put your cursor on the f in foo:

int foo = 5;

2. Place mark m on the f in foo (mm)
3. Run gcO and type " hello". You should now have this:

// hello
int foo = 5;

4. However, mark m is also now on the e in hello. Test this by doing `m to jump to the character the mark is on.

Expected behavior

The expected behavior is that the mark should remain on the f in foo that it was placed on to begin with.

[numToStr]

This seems logical to me not a bug. Mark is at the right range i.e., row and col. Keep in mind, gcO creates a line above, so all the marks that was on the previous line will be shifted.

[PowerUser64]

My initial expectation was the behavior of gcO is it should produce the same result as doing O<Esc>gcc, since that is effectively what it simplifies into one keystroke. It is worth noting that gco does not move marks, but this makes sense given your explanation.

The problem with this behavior and the reason I discovered this is it messes up macros that use marks to keep track of where to operate. In fact, I was running the macro described in my initial comment.

Would it be helpful if I made a PR to resolve this? My current idea for the implementation would be to look for marks on the current line and move them down if adding to a line above the current one. This would go somewhere around line 42 in extra.lua. If you have an idea for an alternative solution, just say so.

[numToStr]

My current idea for the implementation would be to look for marks on the current line and move them down if adding to a line above the current one.

How many marks would you move? the line could've {n} number of marks. I don't think that is a nice solution.

If you have an idea for an alternative solution, just say so.

I don't think there is an issue here to begin with. Marks are already preserved by using lockmarks and it applies to every default keybindings

Comment.nvim/lua/Comment/api.lua

Line 481 in 728f38e

('lockmarks lua require("Comment.api").%s(%s)'):format(cb, motion and ('%q'):format(motion))

[PowerUser64]

the line could've {n} number of marks

Okay, that's fair.

Marks are already preserved by using lockmarks and it applies to every default keybindings

Sure, the marks are staying on the character index they start on, but they're not really staying in the correct place, especially compared to other vim behavior like O. The mark should stay on the character it started on unless the line gets deleted.

Perhaps there's a way to more closely mimic the functionality of O but have it place a comment there too? That would avoid moving any number of marks unless that's what vim does anyway.

[numToStr]

IDK if this would work or not but perhaps, we could remove lockmarks from gc{o,O}. Would you mind checking it (i am on mobile)?

[PowerUser64]

Hey, that fixes it! Now, the mark is left on the character it is placed on to begin with.

Changes are at https://github.com/PowerUser64/Comment.nvim/tree/lockmarks

[PowerUser64]

This makes sense. The vim documentation for :lockmarks reads,

Execute {command} without adjusting marks.  This is
useful when changing text in a way that the line count
will be the same when the change has completed.
WARNING: When the line count does change, marks below
the change will keep their line number, thus move to
another text line.

https://vimhelp.org/motion.txt.html#%3Alockmarks

lockmarks is anchoring the marks to the line number, allowing marks to stay in place when new lines are created; as shown in the example. Without lockmarks, the marks are anchored to where they start, just like normal vim behavior.

[numToStr]

Care to make a PR? We can discuss implementation details there :)

[PowerUser64]

Sure!