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: 3946 bytes --]

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.

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.

On Mon, Dec 16, 2024 at 2:09 PM Filipp Gunbin <fgunbin@fastmail.fm> wrote:

> On 16/12/2024 18:30 +0100, Gerd Möllmann wrote:
>
> > Filipp Gunbin <fgunbin@fastmail.fm> writes:
> >
> >>> Terminal.app's Command-C can only copy a selection that the app knows
> >>> about.
> >>
> >> Not really - with xterm-mouse-mode disabled (and with "Allow mouse
> >> reporting" ticked in Terminal.app menu), mouse selection in Terminal.app
> >> is not related to Emacs selection, and copy / paste works.
> >
> > What I meant with my sentence is that the selection Emacs shows and the
> > selection Terminal.app shows and uses are not related to each other.
> > Maybe that's a cause of confusion, I don't know.
> >
> >>
> >>> If the mouse is used by an app like Emacs (Terminal.app's
> >>> Settings/Report ....)) the user tells Terminal to let the app use the
> mouse.
> >>> I find it little surprising that when Terminal.app does that, it
> doesn't
> >>> use the mouse itself to make a selection it could then copy.
> >>
> >> It does, although that's Terminal.app's "own" selection, not Emacs's.
> >>
> >>> Do Command-A Command-C and see what happens.
> >>>
> >>> Or use Command-R to toggle the mouse reporting setting on the fly.
> >>>
> >>> Or use xclip in Emacs.
> >>>
> >>> Please don't disable xterm-mouse for this.
> >>
> >> Again, it turns out that the new default leads to copy not working at
> >> all, while with previous default you could make selection in
> >> Terminal.app (it's not reflected in Emacs) and then copy.  Paste works
> >> in both cases.  It still looks to me that the old default is better.  If
> >> you enable xterm-mouse-mode, then perhaps you should also use xclip, not
> >> just the mode itself.
> >
> > Mouse support by default is an important feature, IMO. It makes the menu
> > bar usable, or in a future Emacs containing tty child frames tooltips
> > can be shown. Not to mention setting point and what else.
> >
> > What's the positive effect of turning mouse support off by default?
> > Command-C works for users who haven't set up terminal Emacs well enough
> > that they could use M-w, plus in addition don't know Terminal.app well
> > enough to know about Command-R or Fn + mouse.
>
> My point is exactly that Command-C _doesn't work_ for them, with current
> defaults (xterm-mouse-mode on in Emacs; "Allow mouse reporting" ticked -
> which is the default for a new Terminal.app tab, at least here).
>
> > I think it's best if we simply agree to disagree.
>
> I don't think we disagree much, I see the value of xterm-mouse-mode
> (although I like "just text" on tty, no menus etc.), the only thing
> which concerns me (and is the reason for this bug) are "half-broken"
> defaults.  We're discussing whether to disable xterm-mouse-mode only in
> Terminal.app, not everywhere.
>

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