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

[Filipp Gunbin <fgunbin@fastmail.fm>]

On 14/12/2024 10:40 +0100, Gerd Möllmann wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Filipp Gunbin <fgunbin@fastmail.fm>
>>> Cc: shipmints@gmail.com,  74833@debbugs.gnu.org
>>> Date: Fri, 13 Dec 2024 23:32:39 +0300
>>> 
>>> On 13/12/2024 18:49 +0200, Eli Zaretskii wrote:
>>> 
>>> >> From: Filipp Gunbin <fgunbin@fastmail.fm>
>>> >> Cc: Ship Mints <shipmints@gmail.com>,  74833@debbugs.gnu.org
>>> >> Date: Fri, 13 Dec 2024 19:35:15 +0300
>>> >>
>>> >> On 13/12/2024 09:21 +0200, Eli Zaretskii wrote:
>>> >>
>>> >> > So why is this an Emacs bug?  It sounds like the OP expects something
>>> >> > to happen which shouldn't, because the xterm protocol for selections
>>> >> > and the clipboard are not supported by Terminal.app?  In that case,
>>> >> > this could be at best a feature request, not a bug.
>>> >>
>>> >> I'll try to explain differently.
>>> >>
>>> >> Without xterm-mouse-mode you can copy/paste from/into Terminal.app
>>> >> window, looks like Terminal.app gives this ability on its own.  This is
>>> >> not integration with Emacs kill ring, no.  Emacs cursor does not react
>>> >> to mouse clicks, and selection happens with OS mouse pointer.  Paste
>>> >> works rather slow (bad idea to paste large chunks of text), but
>>> >> tolerable.
>>> >>
>>> >> Now, yesterday my daily master build got me xterm-mouse-mode enabled, so
>>> >> I did some testing just out of curiosity.  Most of the things work,
>>> >> including clicking and selection.  However, Command-C now just doesn't
>>> >> copy text to OS clipboard.  And it's non-obvious that you should disable
>>> >> xterm-mouse-mode to be able to copy.
>>> >
>>> > xterm-mouse-mode is supposed to be enabled only on terminals that load
>>> > xterm.el, which means they are xterm-compatible.  Does Terminal.app
>>> > load xterm.el on startup?
>>> 
>>> Terminal.app sets TERM=xterm-256color (this is configurable in "Settings
>>> -> Profiles -> Advanced -> Declare terminal as", I doubt I ever changed
>>> it), so xterm.el should be loaded, yes.
>>> 
>>> Other term-related vars are:
>>> 
>>> TERM_PROGRAM=Apple_Terminal
>>> TERM_PROGRAM_VERSION=453
>>> TERM_SESSION_ID=1251C872-8246-4380-A2AE-ED1F8B649878
>>
>> Then we should amend xterm.el to not allow xterm-mouse on this
>> terminal.  Jared, could you please add such a condition?
>>
>> And I think the Terminal.app developers should be told that pretending
>> to be xterm without full support for all the xterm features is not
>> TRT, and they should stop.  Would someone please file an issue with
>> their issue tracker?
>
> I still think that this is a cockpit error.
>
> 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.

> 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.