Magit: highlighting of selected diff region in magit status buffer is sometimes misleading

[aspiers]

If I position the point within a diff hunk in the magit status buffer, hit C-SPC to mark the beginning of a region, and then hit C-n twice (say) then 3 full lines will be highlighted. This is no doubt as designed, and correct behaviour when considered in relation to the fact that (assuming the point is within the Unstaged changes section) pressing s to stage would add those 3 full lines to the index, even though they are not fully contained within the region between the mark and the point.

However when the intention of marking a region was to copy it via C-w, this behaviour is inconsistent with the rest of emacs, and therefore unintuitive. In the rest of emacs, in this example where the point is after the mark, the point signifies the end of the region, so kill-ring-save would only save the two lines preceding the point, not those two plus the line which the point is currently on.

Another way of describing this difference is that staging/unstaging uses an "inclusive region" which always contains the mark and point but can also extend wider to the first line boundary beyond either of those if necessary, whereas C-w always copies the exact region between the mark and point and no further.

So the question is whether we can somehow make this UI highlighting behaviour more intuitive so that it is consistent both with the common staging/unstaging use case, and the kill-ring-save use case. "No" might well be a reasonable answer here; however it would be nice to consider whether there is a solution before dismissing the possibility altogether ;-)

One crazy idea I had was to simultaneously use the primary and secondary selection. The primary selection would highlight the region to be staged or unstaged if s or u are pressed, and the secondary selection (always inside the primary) would highlight the region to be copied if C-w is pressed. Having said that, this might also confuse users, so maybe as a default it's no less confusing than the current behaviour and would only be acceptable as an option for advanced users who regularly use C-w.

Or maybe someone can come up with a better solution ;-)

AFAIK this isn't really a version-specific issue, but just to play by the issue submission rules, FWIW I'm currently using 20190513.1740 (yes I know, I really need to update).

[npostavs]

If you set magit-keep-region-overlay then the "classic" Emacs region will be visible at the same time.

[kyleam]

however it would be nice to consider whether there is a solution before dismissing the possibility altogether

For past consideration, see the docstring of magit-keep-region-overlay, the message of the commit that added it (371990c15), and the issues referenced by that commit (gh-2085 and gh-2063).

[aspiers]

Ahah, thanks! Despite the warnings in that docstring, this is exactly the behaviour I want. So please consider this a strong vote for keeping this option.

I also find it somewhat difficult to understand why the concerns in 371990c that docstring are expressed so strongly (e.g. that enabling the option is considered a "mistake"). The docstring refers several times to "valid selections", and I assume that every such reference is intended to mean the same as the first reference, i.e. "a valid selection as understood by Magit commands". But to me that demonstrates an assumption that any selection not understood by Magit commands is automatically somehow invalid. Maybe I'm missing something but I disagree with that assumption.

For a start, it seems to ignore magit-copy-section-value which is capable of copying a region which spans across hunks, or even across non-siblings. But I am fairly sure there other use cases we haven't yet thought of, where it makes sense to select regions which most Magit commands do not understand. In fact this approach underlies a whole philosophy behind emacs, which is that pretty much everything the user interacts with is simply text in buffers, and emacs does not prevent the user from operating on that text in whatever way they see fit. Another such example is M-x shell, where you can move the point anywhere within the buffer and even edit past content, despite that being impossible when running a shell within a normal terminal application like xterm. I find this philosophy slightly reminiscent of Larry Wall's famous quote:

Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun.

For similar reasons I really appreciate the flexibility and trust emacs generally extends to its users - I guess you could call me a "UI libertarian" ;-)

Secondly, despite the concerns expressed about the effect that enabling this option has on the face properties of heading, I find the current highlighting behaviour perfectly intuitive.

So in summary, IMHO this option behaves great just as it is, I don't fully understand the concerns expressed around it, but as long as it's kept I'll be happy :-) I guess this issue can be closed now, unless anyone wants to continue the discussion further. Thanks again for the info and the great implementation!

[npostavs]

Secondly, despite the concerns expressed about the effect that enabling this option has on the face properties of heading, I find the current highlighting behaviour perfectly intuitive.

I use it too, though I do find the "classic" region highlighting a bit distracting when I'm intending to use the line-based selection. However, the only solution I can think of to that would be to have different commands for enabling each kind of selection, and that sounds even more distracting.