bug#74833: 31.0.50; Copy to OS clipboard doesn't work in macOS Terminal.app with xterm-mouse-mode enabled

[Ship Mints <shipmints@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2111 bytes --]

Now I see the recent change to master (Dec 9). I'd add that pretty much
every other "curses" based app that supports mouse activity defaults to
mouse on, though. Not sure why Emacs's recent default to on should be
surprising. People would be surprised that the mouse doesn't work. That
Terminal.app also steals command keys from those apps is also not a
surprise.

On Mon, Dec 16, 2024 at 2:58 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Ship Mints <shipmints@gmail.com>
> > Date: Mon, 16 Dec 2024 14:20:40 -0500
> > Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
> >       Eli Zaretskii <eliz@gnu.org>, Jared Finder <jared@finder.org>,
> 74833@debbugs.gnu.org
> >
> > I think about it like this: if Terminal.app successfully passed through
> all its keys (which it can be configured to
> > do), Command-C would appear in Emacs as M-c but it doesn't. Does it
> surprise you that Command-P offers
> > the print dialog when Emacs is running in the terminal? This is no
> different than Command-C. That
> > Terminal.app supersedes Emacs is not an Emacs problem, it's Terminal's
> problem. This feels like
> > documentation issue not something to cure with default Emacs
> configuration.
> >
> > Other terminal applications like iTerm or WezTerm can be programmed
> similarly to pass through all keys
> > that you want them to with modifiers, but by default, they don't. These
> can't be Emacs's problem either.
> > Same with Emacs run via ssh with tmux on the other side. That's a
> "default" set of features offered on many
> > systems and their configuration is not Emacs's problem.
>
> I see your points, but the fact remains that our enabling of
> xterm-mouse-mode triggered these problems where previously there were
> none.
>
> > This issue sounds like an "impedance mismatch" to my ears, even if it
> surprises some users and requires
> > some configuration depending on your specific goals and should perhaps
> be better documented.
>
> If a default behavior needs documentation to explain it, it is usually
> a sign of a not-very-good default, IME.
>

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]