meow-edit
meow-select-on-[change|append|insert] changes where the mark goes
I was playing around a bit with the new select on insert functionality and was looking at activating the region after the fact, but I noticed the variable is in charge of actually setting the mark, not just activating the selection.
Would it be better if the mark is set regardless, then the variables decide if the selection should be left active or not?
Also maybe a meow-activate fallback for meow-reverse?
Do you mean in your case, the region is not activated after exit the INSERT state?
The expected behavior is when you leave INSERT state, there's a region from the point you start to current position.
The functionality works as expected when the variables are set. The thing that I'm thinking about is that when they are not set, the mark isn't moved so if I activate the mark after the fact, then the region is from wherever it was before to point.
If the functions were rewritten to always drop a mark where the insertion begun, then check the variables to see if the region should be active or not; the markring would look the same for both when the variables are t and nil.
An example: (kmacro "v t h i n g <return> a SPC t e x t SPC a f t e r SPC t h i n g <escape>")
meow-select-on-append t:
thing< text after thing|
meow-select-on-append nil:
<thing text after thing|
where < is mark and | is point.
So, the idea is to always have a mark where we enter the insert state. I think it's good, we should do it.
meow-activate is not required, we can use builtin exchange-point-and-mark. I don't know if we should set it as the default fallback behavior for meow-reverse, as it might take your cursor to a place quite far. But it makes logical sense.
True exchange-point-and-mark would maybe be the expected behavior as it would do the same thing, just also activate the region. The jumping away was the reason I was thinking, maybe we want one press to activate, then another to reverse.
I would probably need to try them out and live with them for a while to see if they're nice.
After about 30 sec of playing around with using exchange-point-and-mark as fallback, I agree that maybe it's not great default behavior. It interacts a bit weirdly with meow-cancel-selection (though I will probably keep it myself).
After using exchange-point-and-mark further I think the weird behaviors come from how the mark is moved to not spam the mark-ring, but this is probably better discussed in its own issue, so I will leave that here.
I've been playing around with how to naively implement the mark moving with a disabled region and I realize that I have no clue how activate- and deactivate-mark works. If i put them in a function that does something, then the activate or deactivate does nothing. But if I put it in its own function that I run on its own, then it works as I expect.
I've read that there is some interaction between deactivate-mark variable and things that modify the buffer, but I haven't really gotten anywhere there either.