meow--select: don't spam mark-ring #589
Conversation
For example, without this change, calling `meow-next-word` repeatedly on a selection created by `meow-mark-word` will repeatedly push the position at the beginning of the selection onto the mark-ring. This can quickly overflow the mark-ring, and it makes `pop-to-mark-command` a lot more annoying to use.
|
I think you inspired me that we should only keep one mark for each type of selection no matter how it gets extended. So I probably want to have this patch for all commands, and do it in a better way. |
|
Glad to hear it! The fact that all the Meow motions create selections means that the mark ring automatically becomes a tool for jumping back to previous edit positions. How would you feel about an |
|
Sorry for the late response, yeah, I would like to learn more about your idea. I think current mark-ring usage wasn't good. I'd like to have an improvement here. |
My idea is pretty much what I said in my first comment - since the user moves around and edits using Meow motions, and those motions create selections, the user's movement and edit positions are saved in the mark ring. This means that one can move back to previous positions using But, like you said, this will work better if every selection results in only one position being added to the mark ring. This PR doesn't cover that... |
|
I think we can achieve this simply by comparing the current selection type and new selection type. I'm thinking whether we should keep the same type of first choice or last choice. |
|
Fixed in the latest command, also see Now we have something similar to C-i/C-o in Vim |
For example, without this change, calling
meow-next-wordrepeatedly on a selection created bymeow-mark-wordwill repeatedly push the position at the beginning of the selection onto the mark-ring. This can quickly overflow the mark-ring with identical positions, and it makespop-to-mark-commanda lot more annoying to use.