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

[Jared Finder via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

On 2024-12-14 04:40, 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.

I agree. While in Emacs, with Emacs managing the selection, one should 
expect to use Emacs commands to manage the clipboard like C-w and M-w. 
Sadly, Terminal.app does not support OSC52 therefore the clipboard is 
shared only within Emacs. Terminal.app provides fn+mouse drag to select 
things that Command-C notices as well as Command-R to disable mouse 
reporting already for exactly this reason.

However, I'm sensitive that someone using Terminal.app is just using the 
MacOS default configuration for terminal and will think Emacs is broken 
here. Terminal.app is MacOS's default terminal emulator after all. Other 
popular MacOS terminal emulators like iTerm2 work fine because they 
support OSC52 (copy protocol).

What about adding a workaround that uses the command line tool pbcopy 
(Mac version of xclip)? The pbcopy program is distributed with MacOS by 
default. This won't work over SSH, but at that point I don't think 
there's anything that can be done. TERM_PROGRAM isn't sent to the server 
by default.

I also think I could make the news entry more detailed.


Paste works just fine in MacOS under Terminal.app for me.

   -- MJF