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 15/12/2024 17:41 -0800, Jared Finder wrote:

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

I didn't know about fn + mouse drag, thanks!

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

That's my point, yes.

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

Having thing like that in Emacs, without a need for installing a
package, would be best from my POV.

> I also think I could make the news entry more detailed.
>
>
> Paste works just fine in MacOS under Terminal.app for me.

For me too.