bug#58608: 29.0.50; Nasty bug with pasting primary selection in term buffers

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 20 Oct 2022 11:14:50 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: 58608@debbugs.gnu.org
> 
> > I think it could be important to understand why select-active-regions
> > causes this problem in your case.
> 
> I think mechanically it's because the middle click moves point to the
> click position, and the call to `deactivate-mark' then causes the
> primary selection to be updated based on the current point and mark
> (unless we mess with select-active-regions).
> 
> You've made me wonder, though... this command is intended only for
> term char mode, so should a middle click *really* be setting point?
> If all we're trying to do is send the selection text to the inferior
> process, that bit might be wrong.

It could be, but maybe looking at the Git history of that code will
tell you why we have that part there?  I mean, maybe there are use
cases where that is important?

If nothing comes up, I think you are right, and that move should be
removed.  On a GUI frame, a middle click leaves point _at_the_end_ of
the inserted text, not where I click.

But if we aren't sure, it's okay to momentarily disable
select-active-regions here, we just need a comment with the
explanation you wrote above.

> I'm now looking at that (setq this-command 'yank) as well, and
> wondering whether it's important for anything under the impression
> that a `yank' just happened to also see point at the location of
> the yank.  I'm not sure whether a middle click in a terminal to
> send the primary selection directly to the inferior process *should*
> be treated as `yank' though -- maybe that code is also wrong.

Indeed, we don't by default treat middle click as yank on GUI frames.
So maybe you are right -- but please note that there are some user
options which perhaps do cause the middle click to be treated as yank
as optional behavior, in which case they should do the same in the
term case.