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

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

[Filipp Gunbin]

macOS, Terminal.app, xterm-mouse-mode enabled
emacs -nw -Q
Select something with mouse, press Command-c
Try to paste into another program - text is not in the clipboard

Perhaps this is not new, I just tried xterm-mouse-mode for the first
time, given that it's now the default in master.

Trying different combinations of select-enable-clipboard and
select-enable-primary did not help (that variables are all I know in
this area).

Thanks.


In GNU Emacs 31.0.50 (build 43, aarch64-apple-darwin23.6.0, NS
 appkit-2487.70 Version 14.6 (Build 23G80)) of 2024-12-12 built on
 localhost
Repository revision: 9ccd459e8452cc9e6e81e53f26bbeef20d2d5bb7
Repository branch: master
System Description:  macOS 14.6

Configured using:
 'configure --enable-check-lisp-object-type --with-file-notification=no
 --with-native-compilation=no'

Configured features:
ACL GLIB GNUTLS LCMS2 LIBXML2 MODULES NS PDUMPER PNG RSVG SQLITE3
THREADS TOOLKIT_SCROLL_BARS WEBP XIM ZLIB

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

[Ship Mints]

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

You need something like https://elpa.gnu.org/packages/xclip.html to assist
connecting macOS terminal Emacs to the system pasteboard/clipboard.

On Thu, Dec 12, 2024 at 12:56 PM Filipp Gunbin <fgunbin@fastmail.fm> wrote:

> macOS, Terminal.app, xterm-mouse-mode enabled
> emacs -nw -Q
> Select something with mouse, press Command-c
> Try to paste into another program - text is not in the clipboard
>
> Perhaps this is not new, I just tried xterm-mouse-mode for the first
> time, given that it's now the default in master.
>
> Trying different combinations of select-enable-clipboard and
> select-enable-primary did not help (that variables are all I know in
> this area).
>
> Thanks.
>
>
> In GNU Emacs 31.0.50 (build 43, aarch64-apple-darwin23.6.0, NS
>  appkit-2487.70 Version 14.6 (Build 23G80)) of 2024-12-12 built on
>  localhost
> Repository revision: 9ccd459e8452cc9e6e81e53f26bbeef20d2d5bb7
> Repository branch: master
> System Description:  macOS 14.6
>
> Configured using:
>  'configure --enable-check-lisp-object-type --with-file-notification=no
>  --with-native-compilation=no'
>
> Configured features:
> ACL GLIB GNUTLS LCMS2 LIBXML2 MODULES NS PDUMPER PNG RSVG SQLITE3
> THREADS TOOLKIT_SCROLL_BARS WEBP XIM ZLIB
>
>
>
>

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

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

[Filipp Gunbin]

On 12/12/2024 13:08 -0500, Ship Mints wrote:

> You need something like https://elpa.gnu.org/packages/xclip.html to assist
> connecting macOS terminal Emacs to the system pasteboard/clipboard.

Thanks, BTW paste with Command-V works, it's just copy that doesn't
work.  Probably I'll disable xterm-mouse-mode anyway, but it would be
nice to have this resolved in Emacs.

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

[Ship Mints]

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

I think that's because Terminal.app is providing paste, not Emacs. If you
use Emacs commands to put text into the kill-ring, it has to make it from
there into the pasteboard/clipboard and that's what xclip does for you.

On Thu, Dec 12, 2024 at 1:18 PM Filipp Gunbin <fgunbin@fastmail.fm> wrote:

> On 12/12/2024 13:08 -0500, Ship Mints wrote:
>
> > You need something like https://elpa.gnu.org/packages/xclip.html to
> assist
> > connecting macOS terminal Emacs to the system pasteboard/clipboard.
>
> Thanks, BTW paste with Command-V works, it's just copy that doesn't
> work.  Probably I'll disable xterm-mouse-mode anyway, but it would be
> nice to have this resolved in Emacs.
>

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

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

[Eli Zaretskii]

> From: Filipp Gunbin <fgunbin@fastmail.fm>
> Date: Thu, 12 Dec 2024 20:54:53 +0300
> 
> macOS, Terminal.app, xterm-mouse-mode enabled
> emacs -nw -Q
> Select something with mouse, press Command-c
> Try to paste into another program - text is not in the clipboard
> 
> Perhaps this is not new, I just tried xterm-mouse-mode for the first
> time, given that it's now the default in master.
> 
> Trying different combinations of select-enable-clipboard and
> select-enable-primary did not help (that variables are all I know in
> this area).

Does the macOS Terminal.app support the xterm mouse protocol?

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

[Ship Mints]

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

It supports a subset of mouse behavior via this user setting:

https://support.apple.com/guide/terminal/turn-on-mouse-reporting-trmlc69728a5/2.12/mac/11.0

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

> > From: Filipp Gunbin <fgunbin@fastmail.fm>
> > Date: Thu, 12 Dec 2024 20:54:53 +0300
> >
> > macOS, Terminal.app, xterm-mouse-mode enabled
> > emacs -nw -Q
> > Select something with mouse, press Command-c
> > Try to paste into another program - text is not in the clipboard
> >
> > Perhaps this is not new, I just tried xterm-mouse-mode for the first
> > time, given that it's now the default in master.
> >
> > Trying different combinations of select-enable-clipboard and
> > select-enable-primary did not help (that variables are all I know in
> > this area).
>
> Does the macOS Terminal.app support the xterm mouse protocol?
>
>
>
>

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

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

[Eli Zaretskii]

> From: Ship Mints <shipmints@gmail.com>
> Date: Thu, 12 Dec 2024 14:18:47 -0500
> Cc: Filipp Gunbin <fgunbin@fastmail.fm>, 74833@debbugs.gnu.org
> 
> It supports a subset of mouse behavior via this user setting:
> 
> https://support.apple.com/guide/terminal/turn-on-mouse-reporting-trmlc69728a5/2.12/mac/11.0

That doesn't tell enough.  xterm.el and xterm-mouse assume full
support for the xterm protocols, so partial support could well explain
why things don't work.

In general, I don't recommend turn on xterm features on terminals
other than xterm, unless they are faithful emulations of xterm.

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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ship Mints <shipmints@gmail.com>
>> Date: Thu, 12 Dec 2024 14:18:47 -0500
>> Cc: Filipp Gunbin <fgunbin@fastmail.fm>, 74833@debbugs.gnu.org
>> 
>> It supports a subset of mouse behavior via this user setting:
>> 
>> https://support.apple.com/guide/terminal/turn-on-mouse-reporting-trmlc69728a5/2.12/mac/11.0
>
> That doesn't tell enough.  xterm.el and xterm-mouse assume full
> support for the xterm protocols, so partial support could well explain
> why things don't work.
>
> In general, I don't recommend turn on xterm features on terminals
> other than xterm, unless they are faithful emulations of xterm.

There is, for some reason, a checkbox in Terminal.app Settings dialog
with which one can make Terminal.app not send xterm mouse escape
sequences. If it's off when Emacs runs it doesn't get informed about
mouse clicks and so on. So nothing happens.

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

[Ship Mints]

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

I have xterm-mouse-mode enabled when in tty mode on macOS and it does work
for clicking/selecting but this is independent of integrating the kill ring
with the pasteboard. I am unaware of how to test the completeness of the
xterm mouse protocol support, however.

On Thu, Dec 12, 2024 at 2:32 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Ship Mints <shipmints@gmail.com>
> > Date: Thu, 12 Dec 2024 14:18:47 -0500
> > Cc: Filipp Gunbin <fgunbin@fastmail.fm>, 74833@debbugs.gnu.org
> >
> > It supports a subset of mouse behavior via this user setting:
> >
> >
> https://support.apple.com/guide/terminal/turn-on-mouse-reporting-trmlc69728a5/2.12/mac/11.0
>
> That doesn't tell enough.  xterm.el and xterm-mouse assume full
> support for the xterm protocols, so partial support could well explain
> why things don't work.
>
> In general, I don't recommend turn on xterm features on terminals
> other than xterm, unless they are faithful emulations of xterm.
>

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

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

[Eli Zaretskii]

> From: Ship Mints <shipmints@gmail.com>
> Date: Thu, 12 Dec 2024 15:31:00 -0500
> Cc: fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> 
> I have xterm-mouse-mode enabled when in tty mode on macOS and it does work for clicking/selecting but
> this is independent of integrating the kill ring with the pasteboard. I am unaware of how to test the
> completeness of the xterm mouse protocol support, however.

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.

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

[Ship Mints]

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

I agree. I think OP was expressing surprise at features not working "out of
the box." I suppose macOS terminal xmouse and kill-ring pasteboard
integration deserve a mention in PROBLEMS.

On Fri, Dec 13, 2024 at 2:21 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Ship Mints <shipmints@gmail.com>
> > Date: Thu, 12 Dec 2024 15:31:00 -0500
> > Cc: fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> >
> > I have xterm-mouse-mode enabled when in tty mode on macOS and it does
> work for clicking/selecting but
> > this is independent of integrating the kill ring with the pasteboard. I
> am unaware of how to test the
> > completeness of the xterm mouse protocol support, however.
>
> 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.
>

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

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

[Filipp Gunbin]

On 13/12/2024 09:21 +0200, Eli Zaretskii wrote:

>> From: Ship Mints <shipmints@gmail.com>
>> Date: Thu, 12 Dec 2024 15:31:00 -0500
>> Cc: fgunbin@fastmail.fm, 74833@debbugs.gnu.org
>> 
>> I have xterm-mouse-mode enabled when in tty mode on macOS and it does work for clicking/selecting but
>> this is independent of integrating the kill ring with the pasteboard. I am unaware of how to test the
>> completeness of the xterm mouse protocol support, however.
>
> 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.

That's why I filed this bug - because previous behavior was not ideal
but working, and now only paste works.

Maybe we should just avoid enabling xterm-mouse-mode in Terminal.app.
Maybe functionality of xclip should be in core.

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

[Ship Mints]

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

What you describe is normal behavior, even if it appears confusing. It's an
"impedance mismatch" between terminal.app and being in a "curses" window.
Terminal doesn't "see" selected text and hence Command-C is disabled. This
is the opposite for a basic shell where terminal sees the text because
it controls selection. You can see this by pulling down the Edit menu and
seeing Copy grayed out. As far as how xterm-mouse-mode interferes with
Command-C I'd have to disable it myself and see what's going on. Not sure
how much value that adds, though. If you enable xclip, you'll get what you
want being inside Emacs, after all, using M-w gets your selected text
copied to the pasteboard.

On Fri, Dec 13, 2024 at 11:35 AM Filipp Gunbin <fgunbin@fastmail.fm> wrote:

> On 13/12/2024 09:21 +0200, Eli Zaretskii wrote:
>
> >> From: Ship Mints <shipmints@gmail.com>
> >> Date: Thu, 12 Dec 2024 15:31:00 -0500
> >> Cc: fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> >>
> >> I have xterm-mouse-mode enabled when in tty mode on macOS and it does
> work for clicking/selecting but
> >> this is independent of integrating the kill ring with the pasteboard. I
> am unaware of how to test the
> >> completeness of the xterm mouse protocol support, however.
> >
> > 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.
>
> That's why I filed this bug - because previous behavior was not ideal
> but working, and now only paste works.
>
> Maybe we should just avoid enabling xterm-mouse-mode in Terminal.app.
> Maybe functionality of xclip should be in core.
>

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

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

[Ship Mints]

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

Try experimenting with alternative terminals such as
https://wezfurlong.org/wezterm/ which I've used and where I remap all of
the keys to pass through to Emacs vs. letting the terminal application
abscond with functions like Command-C. I can share my wezterm configuration
off line if you're interested. I still remain mostly GUI on macOS but
occasionally use the terminal, and especially useful for running Emacs via
ssh on a remote computer (vs. tramp).

On Fri, Dec 13, 2024 at 11:42 AM Ship Mints <shipmints@gmail.com> wrote:

> What you describe is normal behavior, even if it appears confusing. It's
> an "impedance mismatch" between terminal.app and being in a "curses"
> window. Terminal doesn't "see" selected text and hence Command-C is
> disabled. This is the opposite for a basic shell where terminal sees the
> text because it controls selection. You can see this by pulling down the
> Edit menu and seeing Copy grayed out. As far as how xterm-mouse-mode
> interferes with Command-C I'd have to disable it myself and see what's
> going on. Not sure how much value that adds, though. If you enable xclip,
> you'll get what you want being inside Emacs, after all, using M-w gets your
> selected text copied to the pasteboard.
>
> On Fri, Dec 13, 2024 at 11:35 AM Filipp Gunbin <fgunbin@fastmail.fm>
> wrote:
>
>> On 13/12/2024 09:21 +0200, Eli Zaretskii wrote:
>>
>> >> From: Ship Mints <shipmints@gmail.com>
>> >> Date: Thu, 12 Dec 2024 15:31:00 -0500
>> >> Cc: fgunbin@fastmail.fm, 74833@debbugs.gnu.org
>> >>
>> >> I have xterm-mouse-mode enabled when in tty mode on macOS and it does
>> work for clicking/selecting but
>> >> this is independent of integrating the kill ring with the pasteboard.
>> I am unaware of how to test the
>> >> completeness of the xterm mouse protocol support, however.
>> >
>> > 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.
>>
>> That's why I filed this bug - because previous behavior was not ideal
>> but working, and now only paste works.
>>
>> Maybe we should just avoid enabling xterm-mouse-mode in Terminal.app.
>> Maybe functionality of xclip should be in core.
>>
>

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

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

[Filipp Gunbin]

On 13/12/2024 11:52 -0500, Ship Mints wrote:

> Try experimenting with alternative terminals such as
> https://wezfurlong.org/wezterm/ which I've used and where I remap all of
> the keys to pass through to Emacs vs. letting the terminal application
> abscond with functions like Command-C. I can share my wezterm configuration
> off line if you're interested. I still remain mostly GUI on macOS but
> occasionally use the terminal, and especially useful for running Emacs via
> ssh on a remote computer (vs. tramp).

Thank you for the tips!  I'm certainly fine with xterm-mouse-mode off,
this bug is rather to let people know that the _default_ behavior
worsened, in default macOS terminal.

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

[Eli Zaretskii]

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

> Maybe we should just avoid enabling xterm-mouse-mode in Terminal.app.

It should already be so, AFAIU.

> Maybe functionality of xclip should be in core.

Only if its developer submits it for inclusion.

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

[Filipp Gunbin]

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

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

[Ship Mints]

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

I'm afraid to say that TERM indicates terminfo support, not whether
terminal.app provides full xterm compatibility which I believe it doesn't,
at least not without manual modifications to the key maps and I can't speak
to other xterm features. This will require some experimentation. Give
xterm.el a try and see how it goes. I would not load that by default
without conformance testing of some kind. I suppose it would already have
been by now if it was known to work.

Take a look at this page
https://dotat.at/@/2020-12-12-terminal-app-xterm-compatibiity.html someone
did some work in this regard. I might give some of this a try myself one
day.

On Fri, Dec 13, 2024 at 3:32 PM Filipp Gunbin <fgunbin@fastmail.fm> wrote:

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

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

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

[Eli Zaretskii]

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

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

[Gerd Möllmann]

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

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.

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

[Filipp Gunbin]

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.

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

[Gerd Möllmann]

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.

I think it's best if we simply agree to disagree. 

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

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Jared Finder <jared@finder.org>,
>   74833@debbugs.gnu.org,  shipmints@gmail.com
> Date: Mon, 16 Dec 2024 18:30:30 +0100
> 
> 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.

I agree that mouse support is an important feature -- if it works well
and doesn't cause regressions.  Here it seems like at least some
people could see some breakage.

It is easy to turn on xterm-mouse-mode for those who want it and don't
get anything broken due to it.  Turning it on by default is only TRT
if there are no significant downsides.  IOW, we shouldn't force users
to turn off some feature that is turned on by default because the
default doesn't work or breaks something.

So I still think it is safer to turn this off on Terminal.app, if we
can detect it.

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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Jared Finder <jared@finder.org>,
>>   74833@debbugs.gnu.org,  shipmints@gmail.com
>> Date: Mon, 16 Dec 2024 18:30:30 +0100
>> 
>> 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.
>
> I agree that mouse support is an important feature -- if it works well
> and doesn't cause regressions.  Here it seems like at least some
> people could see some breakage.
>
> It is easy to turn on xterm-mouse-mode for those who want it and don't
> get anything broken due to it.  Turning it on by default is only TRT
> if there are no significant downsides.  IOW, we shouldn't force users
> to turn off some feature that is turned on by default because the
> default doesn't work or breaks something.

You left out the part where I said for whom it breaks something :-).

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

[Filipp Gunbin]

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.

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

[Ship Mints]

[-- 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 --]

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

[Gerd Möllmann]

Ship Mints <shipmints@gmail.com> writes:

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

Right. It's the support for the Kitty Keyboard Protocol, which allows
this. Which Emacs doesn't support OOTB, only through the kkp package.

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

[Eli Zaretskii]

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

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

[Ship Mints]

[-- 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 --]

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

[Eli Zaretskii]

> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 16 Dec 2024 15:07:25 -0500
> Cc: fgunbin@fastmail.fm, gerd.moellmann@gmail.com, jared@finder.org, 
> 	74833@debbugs.gnu.org
> 
> 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.

First, xt-mouse is not about curses, it's about xterm-specific mouse
protocol.

And second, the issue here, at least for me, is not the user surprise
that the mouse works, it's that features which used to work in Emacs
when running on Terminal.app before that change cease to work, at
least in some situations, now.

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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ship Mints <shipmints@gmail.com>
>> Date: Mon, 16 Dec 2024 15:07:25 -0500
>> Cc: fgunbin@fastmail.fm, gerd.moellmann@gmail.com, jared@finder.org, 
>> 	74833@debbugs.gnu.org
>> 
>> 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.
>
> First, xt-mouse is not about curses, it's about xterm-specific mouse
> protocol.

Replace "curses" which he put in quotes with terminal application and
what Ship Mints says is true.

> And second, the issue here, at least for me, is not the user surprise
> that the mouse works, it's that features which used to work in Emacs
> when running on Terminal.app before that change cease to work, at
> least in some situations, now.

I really don't know what you are talking about when you write "feature
in Emacs". There is no feature _in_ Emacs that is broken. Emacs doesn't
even get a keyboard event for Command-C, it has no idea what is going
on.

It's Terminal.app that behaves differently. And Terminal.app has
previsions for that (Command-R, Fn-mouse).

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

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Ship Mints <shipmints@gmail.com>,  fgunbin@fastmail.fm,
>   jared@finder.org,  74833@debbugs.gnu.org
> Date: Tue, 17 Dec 2024 04:32:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And second, the issue here, at least for me, is not the user surprise
> > that the mouse works, it's that features which used to work in Emacs
> > when running on Terminal.app before that change cease to work, at
> > least in some situations, now.
> 
> I really don't know what you are talking about when you write "feature
> in Emacs". There is no feature _in_ Emacs that is broken. Emacs doesn't
> even get a keyboard event for Command-C, it has no idea what is going
> on.
> 
> It's Terminal.app that behaves differently. And Terminal.app has
> previsions for that (Command-R, Fn-mouse).

I don't see how this distinction (which I have no doubt is accurate)
is important to the decision we should make here.  Simply put,
"something" that worked on Terminal.app before we turned on xt-moude
doesn't work in some cases after we turned it on.  That's my bother.

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

[Ship Mints]

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

I see your point, Eli, for sure. Since this is on master, and presumably
destined for Emacs 31, there seems to be sufficient time for people to read
NEWS and PROBLEMS and accommodate their configurations while Emacs is
brought one step forward into behaving, by default, like other terminal
apps on macOS.

I think someone suggested bringing xclip (seems properly licensed) into the
core and now might be a good time to consider that.

On Tue, Dec 17, 2024 at 1:32 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
> > Cc: Ship Mints <shipmints@gmail.com>,  fgunbin@fastmail.fm,
> >   jared@finder.org,  74833@debbugs.gnu.org
> > Date: Tue, 17 Dec 2024 04:32:20 +0100
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > And second, the issue here, at least for me, is not the user surprise
> > > that the mouse works, it's that features which used to work in Emacs
> > > when running on Terminal.app before that change cease to work, at
> > > least in some situations, now.
> >
> > I really don't know what you are talking about when you write "feature
> > in Emacs". There is no feature _in_ Emacs that is broken. Emacs doesn't
> > even get a keyboard event for Command-C, it has no idea what is going
> > on.
> >
> > It's Terminal.app that behaves differently. And Terminal.app has
> > previsions for that (Command-R, Fn-mouse).
>
> I don't see how this distinction (which I have no doubt is accurate)
> is important to the decision we should make here.  Simply put,
> "something" that worked on Terminal.app before we turned on xt-moude
> doesn't work in some cases after we turned it on.  That's my bother.
>

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

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]

On 2024-12-18 09:50, Ship Mints wrote:
> On Tue, Dec 17, 2024 at 1:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
>> I don't see how this distinction (which I have no doubt is accurate)
>> is important to the decision we should make here.  Simply put,
>> "something" that worked on Terminal.app before we turned on xt-moude
>> doesn't work in some cases after we turned it on.  That's my bother.
> I see your point, Eli, for sure. Since this is on master, and 
> presumably destined for Emacs 31, there seems to be sufficient time for 
> people to read NEWS and PROBLEMS and accommodate their configurations 
> while Emacs is brought one step forward into behaving, by default, like 
> other terminal apps on macOS.
> 
> I think someone suggested bringing xclip (seems properly licensed) into 
> the core and now might be a good time to consider that.

This seems like a good idea to me too. I think we'd also want a variable 
to disable auto-enabling xclip-mode (let's call it 
"xterm-enable-xclip-fallback" and assume it defaults to t). So when 
Emacs detects it is running in Terminal.app and 
xterm-enable-xclip-fallback is set, it enables xclip-mode. In all other 
cases, no change is made.

This does still result in a user-facing behavior change: instead of 
pressing Command-c, a user would have to press Emacs' key binding, M-w 
(or C-c if cua-mode is enabled).

   -- MJF

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

[Ship Mints]

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

I took a look at xclip's code, and its scope is larger than just macOS
pasteboard integration. If I volunteered to help adopt xclip into Emacs,
I'd have no easy way to test its scope beyond macOS. Perhaps it should
remain an external package and people just install when needed. Equivalent
mac-specific pasteboard integration could live in ns-win.el and be narrower
in scope just for macOS users.

As far as the proposed user option goes, "fallback" doesn't really convey
any meaning to me. I know eglot adopted the convention "stay out of" to
control that minor mode's enabling other minor modes. Perhaps a user option
called xterm-stay-out-of-xclip, if that's a convention that people would
like, or xterm-inhibit-enabling-xclip following long-standing Emacs inhibit
conventions. This is moot until xclip becomes part of Emacs.



On Thu, Dec 19, 2024 at 6:16 AM Jared Finder <jared@finder.org> wrote:

> On 2024-12-18 09:50, Ship Mints wrote:
> > On Tue, Dec 17, 2024 at 1:32 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >> I don't see how this distinction (which I have no doubt is accurate)
> >> is important to the decision we should make here.  Simply put,
> >> "something" that worked on Terminal.app before we turned on xt-moude
> >> doesn't work in some cases after we turned it on.  That's my bother.
> > I see your point, Eli, for sure. Since this is on master, and
> > presumably destined for Emacs 31, there seems to be sufficient time for
> > people to read NEWS and PROBLEMS and accommodate their configurations
> > while Emacs is brought one step forward into behaving, by default, like
> > other terminal apps on macOS.
> >
> > I think someone suggested bringing xclip (seems properly licensed) into
> > the core and now might be a good time to consider that.
>
> This seems like a good idea to me too. I think we'd also want a variable
> to disable auto-enabling xclip-mode (let's call it
> "xterm-enable-xclip-fallback" and assume it defaults to t). So when
> Emacs detects it is running in Terminal.app and
> xterm-enable-xclip-fallback is set, it enables xclip-mode. In all other
> cases, no change is made.
>
> This does still result in a user-facing behavior change: instead of
> pressing Command-c, a user would have to press Emacs' key binding, M-w
> (or C-c if cua-mode is enabled).
>
>    -- MJF
>

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

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]

On 2024-12-19 09:23, Ship Mints wrote:
> On Thu, Dec 19, 2024 at 6:16 AM Jared Finder <jared@finder.org> wrote:
>> On 2024-12-18 09:50, Ship Mints wrote:
>>> 
>>> I think someone suggested bringing xclip (seems properly licensed) 
>>> into
>>> the core and now might be a good time to consider that.
>> 
>> This seems like a good idea to me too. I think we'd also want a 
>> variable
>> to disable auto-enabling xclip-mode (let's call it
>> "xterm-enable-xclip-fallback" and assume it defaults to t). So when
>> Emacs detects it is running in Terminal.app and
>> xterm-enable-xclip-fallback is set, it enables xclip-mode. In all 
>> other
>> cases, no change is made.
>> 
>> This does still result in a user-facing behavior change: instead of
>> pressing Command-c, a user would have to press Emacs' key binding, M-w
>> (or C-c if cua-mode is enabled).
>> 
> I took a look at xclip's code, and its scope is larger than just macOS 
> pasteboard integration. If I volunteered to help adopt xclip into 
> Emacs, I'd have no easy way to test its scope beyond macOS. Perhaps it 
> should remain an external package and people just install when needed. 
> Equivalent mac-specific pasteboard integration could live in ns-win.el 
> and be narrower in scope just for macOS users.

I tried a handful of terminal in Linux and it appears that while the 
majority support OSC 52, a significant amount of them don't. The biggest 
gap is all the vte based ones like Gnome Terminal or XFCE Terminal. 
These are their windowing system's default terminals, so there's likely 
a lot of usage here.

If we want to ensure mouse drag to highlight, copy within the terminal 
Emacs, followed by a paste outside of the terminal still work we would 
need to bring xclip into core. I think this would be generally good to 
do anyways. I didn't know about the xclip package and it would have 
significantly improved my workflows with xterm-mouse-mode. I suspect 
many other users of xterm-mouse-mode are in the same boat.

   -- MJF

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I took a look at xclip's code, and its scope is larger than just macOS
  > pasteboard integration. If I volunteered to help adopt xclip into Emacs,

Merging the application program xclip into Emacs seems like doing
things the roundabout way.  Doesn't Emacs already have access to the X
clipboard and selections?  If it doesn't have all the desirable
features in that area, we can implement the missing ones simply
like the already-implemened ones.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Gerd Möllmann]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I took a look at xclip's code, and its scope is larger than just macOS
>   > pasteboard integration. If I volunteered to help adopt xclip into Emacs,
>
> Merging the application program xclip into Emacs seems like doing
> things the roundabout way.  Doesn't Emacs already have access to the X
> clipboard and selections?  If it doesn't have all the desirable
> features in that area, we can implement the missing ones simply
> like the already-implemened ones.

The 'xclip' meant here is the ELPA package

  https://elpa.gnu.org/packages/xclip.html

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: jared@finder.org, gerd.moellmann@gmail.com, eliz@gnu.org,
> 	fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> Date: Sat, 21 Dec 2024 23:49:28 -0500
> 
>   > I took a look at xclip's code, and its scope is larger than just macOS
>   > pasteboard integration. If I volunteered to help adopt xclip into Emacs,
> 
> Merging the application program xclip into Emacs seems like doing
> things the roundabout way.  Doesn't Emacs already have access to the X
> clipboard and selections?  If it doesn't have all the desirable
> features in that area, we can implement the missing ones simply
> like the already-implemened ones.

The xclip package is about allowing Emacs to access the clipboard and
selection from text-only frames.  That is supported on xterm and on
some other text terminals, but not universally.  This package is
supposed to fill the gaps by using external programs.

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

[Ship Mints]

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

You should be able to paste using the (annoying, yes) CUA key Shift-Ins vs.
right mouse button.

I think the only way to know for sure you're under putty is to change your
putty configuration to set/send a custom environment variable that you can
test. I do not recall one that it sets/sends by default beyond TERM which
is "xterm" and that's obviously insufficient.

On Mon, Dec 23, 2024 at 1:47 PM Eli Zaretskii <eliz@gnu.org> wrote:

> I found one more case where turning on xterm-mouse-mode by default
> causes problems: PuTTY.  It loses the ability to paste from the
> Windows clipboard by a right mouse click when xterm-mouse-mode is
> turned on.
>
> Can we identify PuTTY in some way, so that xterm-mouse-mode could not
> be turned on in that case?
>

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

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

[Eli Zaretskii]

> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 23 Dec 2024 14:36:34 +0100
> Cc: jared@finder.org, rms@gnu.org, gerd.moellmann@gmail.com, 
> 	fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> 
> You should be able to paste using the (annoying, yes) CUA key Shift-Ins vs. right mouse button.

Yes, but that works also without xterm-mouse-mode.  My point is that I
lose the paste by mouse.

> I think the only way to know for sure you're under putty is to change your putty configuration to set/send a
> custom environment variable that you can test. I do not recall one that it sets/sends by default beyond TERM
> which is "xterm" and that's obviously insufficient.

You will have to tell more, as I didn't see anything like that.

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

[Ship Mints]

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

Away from a computer, but I think this is still the same in 0.82 these days
and I assume you're using modern ssh.

https://serverfault.com/a/819740

-Stephane

On Mon, Dec 23, 2024 at 14:56 Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Ship Mints <shipmints@gmail.com>
> > Date: Mon, 23 Dec 2024 14:36:34 +0100
> > Cc: jared@finder.org, rms@gnu.org, gerd.moellmann@gmail.com,
> >       fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> >
> > You should be able to paste using the (annoying, yes) CUA key Shift-Ins
> vs. right mouse button.
>
> Yes, but that works also without xterm-mouse-mode.  My point is that I
> lose the paste by mouse.
>
> > I think the only way to know for sure you're under putty is to change
> your putty configuration to set/send a
> > custom environment variable that you can test. I do not recall one that
> it sets/sends by default beyond TERM
> > which is "xterm" and that's obviously insufficient.
>
> You will have to tell more, as I didn't see anything like that.
>

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

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

[Eli Zaretskii]

> From: Ship Mints <shipmints@gmail.com>
> Date: Mon, 23 Dec 2024 15:44:02 +0100
> Cc: jared@finder.org, rms@gnu.org, gerd.moellmann@gmail.com, 
> 	fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> 
> Away from a computer, but I think this is still the same in 0.82 these days and I assume you're using modern
> ssh. 
> 
> https://serverfault.com/a/819740

OK, so does this mean we want to tell PuTTY users to configure this in
some specific way that Emacs can recognize?

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

[Ship Mints]

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

Still away from a computer. If you can set a variable using that method and
have it pass through for you to test in lisp, then it would be a good idea
to recommend. We could suggest using TERM_PROGRAM and setting it to "Putty".

On Mon, Dec 23, 2024 at 4:07 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Ship Mints <shipmints@gmail.com>
> > Date: Mon, 23 Dec 2024 15:44:02 +0100
> > Cc: jared@finder.org, rms@gnu.org, gerd.moellmann@gmail.com,
> >       fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> >
> > Away from a computer, but I think this is still the same in 0.82 these
> days and I assume you're using modern
> > ssh.
> >
> > https://serverfault.com/a/819740
>
> OK, so does this mean we want to tell PuTTY users to configure this in
> some specific way that Emacs can recognize?
>

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

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]

On 2024-12-23 11:43, Ship Mints wrote:
> On Mon, Dec 23, 2024 at 4:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Ship Mints <shipmints@gmail.com>
>>> 
>>> Away from a computer, but I think this is still the same in 0.82 
>>> these days and I assume you're using modern
>>> ssh.
>>> 
>>> https://serverfault.com/a/819740
>> 
>> OK, so does this mean we want to tell PuTTY users to configure this in
>> some specific way that Emacs can recognize?
> 
> Still away from a computer. If you can set a variable using that method 
> and have it pass through for you to test in lisp, then it would be a 
> good idea to recommend. We could suggest using TERM_PROGRAM and setting 
> it to "Putty".

What if we only auto-enabled xterm-mouse-mode on OSC52 compatible 
terminals? Between $TERM and the results from the terminal escape 
sequence "ESC [ > 0 q", Emacs can have high confidence if it is running 
on an OSC52 compatible terminal. I checked against most of the terminals 
mentioned at 
https://can-i-use-terminal.github.io/features/osc52copy.html I just 
wasn't able to test Foot (Wayland-only), hterm (Chromebook-only), mintty 
(Cygwin-only), or xterm.js (I have no idea how to test).

   -- MJF

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

[Eli Zaretskii]

> Date: Thu, 26 Dec 2024 15:51:14 -0800
> From: Jared Finder <jared@finder.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, gerd.moellmann@gmail.com,
>  fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> 
> On 2024-12-23 11:43, Ship Mints wrote:
> > On Mon, Dec 23, 2024 at 4:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >>> From: Ship Mints <shipmints@gmail.com>
> >>> 
> >>> Away from a computer, but I think this is still the same in 0.82 
> >>> these days and I assume you're using modern
> >>> ssh.
> >>> 
> >>> https://serverfault.com/a/819740
> >> 
> >> OK, so does this mean we want to tell PuTTY users to configure this in
> >> some specific way that Emacs can recognize?
> > 
> > Still away from a computer. If you can set a variable using that method 
> > and have it pass through for you to test in lisp, then it would be a 
> > good idea to recommend. We could suggest using TERM_PROGRAM and setting 
> > it to "Putty".
> 
> What if we only auto-enabled xterm-mouse-mode on OSC52 compatible 
> terminals?

On OSC52 compatible terminals, or on OSC52 compatible terminals that
define TERM to xterm-like string?  The latter sounds like a good idea
to me, but only if support for OSC52 necessarily means xterm-mouse
escape sequences must be supported.  Is this conjecture indeed true?

> Between $TERM and the results from the terminal escape 
> sequence "ESC [ > 0 q", Emacs can have high confidence if it is running 
> on an OSC52 compatible terminal. I checked against most of the terminals 
> mentioned at 
> https://can-i-use-terminal.github.io/features/osc52copy.html I just 
> wasn't able to test Foot (Wayland-only), hterm (Chromebook-only), mintty 
> (Cygwin-only), or xterm.js (I have no idea how to test).

How do I check this? can you show some script or Lisp or whatever you
used to check?

Thanks.

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]

On 2024-12-27 00:02, Eli Zaretskii wrote:
>> Date: Thu, 26 Dec 2024 15:51:14 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, rms@gnu.org, 
>> gerd.moellmann@gmail.com,
>>  fgunbin@fastmail.fm, 74833@debbugs.gnu.org
>> 
>> On 2024-12-23 11:43, Ship Mints wrote:
>> > On Mon, Dec 23, 2024 at 4:07 PM Eli Zaretskii <eliz@gnu.org> wrote:
>> >>> From: Ship Mints <shipmints@gmail.com>
>> >>>
>> >>> Away from a computer, but I think this is still the same in 0.82
>> >>> these days and I assume you're using modern
>> >>> ssh.
>> >>>
>> >>> https://serverfault.com/a/819740
>> >>
>> >> OK, so does this mean we want to tell PuTTY users to configure this in
>> >> some specific way that Emacs can recognize?
>> >
>> > Still away from a computer. If you can set a variable using that method
>> > and have it pass through for you to test in lisp, then it would be a
>> > good idea to recommend. We could suggest using TERM_PROGRAM and setting
>> > it to "Putty".
>> 
>> What if we only auto-enabled xterm-mouse-mode on OSC52 compatible
>> terminals?
> 
> On OSC52 compatible terminals, or on OSC52 compatible terminals that
> define TERM to xterm-like string?  The latter sounds like a good idea
> to me, but only if support for OSC52 necessarily means xterm-mouse
> escape sequences must be supported.  Is this conjecture indeed true?

I'm proposing Emacs have a manually curated allow list for now for 
auto-enabling xterm-mouse-mode. Being OSC52 compatible gets us the copy 
/ paste issue this bug mentioned. We can add other conditions going 
forward.

>> Between $TERM and the results from the terminal escape
>> sequence "ESC [ > 0 q", Emacs can have high confidence if it is 
>> running
>> on an OSC52 compatible terminal. I checked against most of the 
>> terminals
>> mentioned at
>> https://can-i-use-terminal.github.io/features/osc52copy.html I just
>> wasn't able to test Foot (Wayland-only), hterm (Chromebook-only), 
>> mintty
>> (Cygwin-only), or xterm.js (I have no idea how to test).
> 
> How do I check this? can you show some script or Lisp or whatever you
> used to check?

Run the following lisp code in Emacs:

(progn
   (send-string-to-terminal "\e[>0q")
   (let ((str "")
         chr)
     (while (setq chr (xterm--read-event-for-query))
       (setq str (concat str (string chr))))
     str))

You should get the string "\eP>|terminal name and version\e\\". For 
example, under iTerm2 I get iTerm2 3.5.10 as the terminal name and 
version and under Kitty I get kitty(0.38.1).

   -- MJF

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

[Eli Zaretskii]

> Date: Fri, 27 Dec 2024 23:08:27 -0800
> From: Jared Finder <jared@finder.org>
> Cc: shipmints@gmail.com, rms@gnu.org, gerd.moellmann@gmail.com,
>  fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> 
> >> What if we only auto-enabled xterm-mouse-mode on OSC52 compatible
> >> terminals?
> > 
> > On OSC52 compatible terminals, or on OSC52 compatible terminals that
> > define TERM to xterm-like string?  The latter sounds like a good idea
> > to me, but only if support for OSC52 necessarily means xterm-mouse
> > escape sequences must be supported.  Is this conjecture indeed true?
> 
> I'm proposing Emacs have a manually curated allow list for now for 
> auto-enabling xterm-mouse-mode. Being OSC52 compatible gets us the copy 
> / paste issue this bug mentioned. We can add other conditions going 
> forward.

What would this allow list specify, and in what terms?

When reading your proposal above, I thought we have a means of testing
the OSC52 support, but now you seem to be saying that this support
should be somehow specified by a database of terminals we maintain?
ANd if so, the question of detecting a non-xterm terminal that sets
TERM to xterm but doesn't support OSC52 still stands, doesn't it?

> >> Between $TERM and the results from the terminal escape
> >> sequence "ESC [ > 0 q", Emacs can have high confidence if it is 
> >> running
> >> on an OSC52 compatible terminal. I checked against most of the 
> >> terminals
> >> mentioned at
> >> https://can-i-use-terminal.github.io/features/osc52copy.html I just
> >> wasn't able to test Foot (Wayland-only), hterm (Chromebook-only), 
> >> mintty
> >> (Cygwin-only), or xterm.js (I have no idea how to test).
> > 
> > How do I check this? can you show some script or Lisp or whatever you
> > used to check?
> 
> Run the following lisp code in Emacs:
> 
> (progn
>    (send-string-to-terminal "\e[>0q")
>    (let ((str "")
>          chr)
>      (while (setq chr (xterm--read-event-for-query))
>        (setq str (concat str (string chr))))
>      str))
> 
> You should get the string "\eP>|terminal name and version\e\\". For 
> example, under iTerm2 I get iTerm2 3.5.10 as the terminal name and 
> version and under Kitty I get kitty(0.38.1).

And if the terminal does NOT support OSC52, what should I expect to
happen?

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]

On 2024-12-28 00:54, Eli Zaretskii wrote:
>> Date: Fri, 27 Dec 2024 23:08:27 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: shipmints@gmail.com, rms@gnu.org, gerd.moellmann@gmail.com,
>>  fgunbin@fastmail.fm, 74833@debbugs.gnu.org
>> 
>> >> What if we only auto-enabled xterm-mouse-mode on OSC52 compatible
>> >> terminals?
>> >
>> > On OSC52 compatible terminals, or on OSC52 compatible terminals that
>> > define TERM to xterm-like string?  The latter sounds like a good idea
>> > to me, but only if support for OSC52 necessarily means xterm-mouse
>> > escape sequences must be supported.  Is this conjecture indeed true?
>> 
>> I'm proposing Emacs have a manually curated allow list for now for
>> auto-enabling xterm-mouse-mode. Being OSC52 compatible gets us the 
>> copy
>> / paste issue this bug mentioned. We can add other conditions going
>> forward.
> 
> What would this allow list specify, and in what terms?
> 
> When reading your proposal above, I thought we have a means of testing
> the OSC52 support, but now you seem to be saying that this support
> should be somehow specified by a database of terminals we maintain?
> ANd if so, the question of detecting a non-xterm terminal that sets
> TERM to xterm but doesn't support OSC52 still stands, doesn't it?

Yes, that's right. Unfortunately we are limited in two ways:

1. Setting TERM to xterm is commonly done by alternative terminals, even 
though they do not fully support all of xterm's functionality. I'd 
estimate that over 80% of alternative terminals just set TERM to 
xterm-256color. This includes the default terminals for Mac 
(Terminal.app), Windows (Windows Terminal), GNOME (GNOME Terminal), and 
KDE (Konsole).
2. There is no way to check if OSC52 is supported.

>> >> Between $TERM and the results from the terminal escape
>> >> sequence "ESC [ > 0 q", Emacs can have high confidence if it is
>> >> running
>> >> on an OSC52 compatible terminal. I checked against most of the
>> >> terminals
>> >> mentioned at
>> >> https://can-i-use-terminal.github.io/features/osc52copy.html I just
>> >> wasn't able to test Foot (Wayland-only), hterm (Chromebook-only),
>> >> mintty
>> >> (Cygwin-only), or xterm.js (I have no idea how to test).
>> >
>> > How do I check this? can you show some script or Lisp or whatever you
>> > used to check?
>> 
>> Run the following lisp code in Emacs:
>> 
>> (progn
>>    (send-string-to-terminal "\e[>0q")
>>    (let ((str "")
>>          chr)
>>      (while (setq chr (xterm--read-event-for-query))
>>        (setq str (concat str (string chr))))
>>      str))
>> 
>> You should get the string "\eP>|terminal name and version\e\\". For
>> example, under iTerm2 I get iTerm2 3.5.10 as the terminal name and
>> version and under Kitty I get kitty(0.38.1).
> 
> And if the terminal does NOT support OSC52, what should I expect to
> happen?

I'm proposing to add a single regexp that matches against the terminal 
name and version string. If there's a match, automatically enable 
xterm-mouse-mode. For terminals that aren't supported or don't support 
"\e[>0q", leave xterm-mouse-mode as is. No other complexity is needed. A 
user can always customize xterm-mouse-mode (it's a user option) if they 
want to enable it anyways.

   -- MJF

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

[Eli Zaretskii]

> Date: Sat, 28 Dec 2024 21:16:28 -0800
> From: Jared Finder <jared@finder.org>
> Cc: shipmints@gmail.com, rms@gnu.org, gerd.moellmann@gmail.com,
>  fgunbin@fastmail.fm, 74833@debbugs.gnu.org
> 
> I'm proposing to add a single regexp that matches against the terminal 
> name and version string. If there's a match, automatically enable 
> xterm-mouse-mode. For terminals that aren't supported or don't support 
> "\e[>0q", leave xterm-mouse-mode as is. No other complexity is needed. A 
> user can always customize xterm-mouse-mode (it's a user option) if they 
> want to enable it anyways.

Sounds okay, but can you post a patch to try?

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

[Gerd Möllmann]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

>> 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.  
  
I disagree completely :-). I don't see "half-broken" defaults.

> We're discussing whether to disable xterm-mouse-mode only in
> Terminal.app, not everywhere.

I don't think it's proven that only Terminal.app behaves the way it
does. At least iTerm can be configured in a way that it behaves almost
the same. And Alacritty as well.

Without seeing Command-C in Emacs, and then doing something to bring
Emacs' selection to the pasteboard, it's pretty difficult for a terminal
emulator to know what's going on in the app. It would have to be a
clairvoyant.

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

[Filipp Gunbin]

On 16/12/2024 20:53 +0100, Gerd Möllmann wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>>> 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.  
>   
> I disagree completely :-). I don't see "half-broken" defaults.

What is the default value of "Allow mouse reporting" if you open a new
Terminal.app tab?  If it's ticked, like here, then you see them :-)
Because then you get by default that half-way setup which I'm
complaining about.

>> We're discussing whether to disable xterm-mouse-mode only in
>> Terminal.app, not everywhere.
>
> I don't think it's proven that only Terminal.app behaves the way it
> does. At least iTerm can be configured in a way that it behaves almost
> the same. And Alacritty as well.

Terminal.app is the default terminal on macOS, so it's a bit more
important in this context than others, I think.  And we're talking about
what Terminal.app does by default.

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

[Ship Mints]

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

On mac, mouse reporting defaults to on and I think always has. "By default,
each new Terminal window has the Allow Mouse Reporting option selected."
Via
https://support.apple.com/guide/terminal/turn-on-mouse-reporting-trmlc69728a5/mac

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

> On 16/12/2024 20:53 +0100, Gerd Möllmann wrote:
>
> > Filipp Gunbin <fgunbin@fastmail.fm> writes:
> >
> >>> 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.
> >
> > I disagree completely :-). I don't see "half-broken" defaults.
>
> What is the default value of "Allow mouse reporting" if you open a new
> Terminal.app tab?  If it's ticked, like here, then you see them :-)
> Because then you get by default that half-way setup which I'm
> complaining about.
>
> >> We're discussing whether to disable xterm-mouse-mode only in
> >> Terminal.app, not everywhere.
> >
> > I don't think it's proven that only Terminal.app behaves the way it
> > does. At least iTerm can be configured in a way that it behaves almost
> > the same. And Alacritty as well.
>
> Terminal.app is the default terminal on macOS, so it's a bit more
> important in this context than others, I think.  And we're talking about
> what Terminal.app does by default.
>

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

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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Filipp Gunbin <fgunbin@fastmail.fm>
>> Date: Thu, 12 Dec 2024 20:54:53 +0300
>> 
>> macOS, Terminal.app, xterm-mouse-mode enabled
>> emacs -nw -Q
>> Select something with mouse, press Command-c
>> Try to paste into another program - text is not in the clipboard
>> 
>> Perhaps this is not new, I just tried xterm-mouse-mode for the first
>> time, given that it's now the default in master.
>> 
>> Trying different combinations of select-enable-clipboard and
>> select-enable-primary did not help (that variables are all I know in
>> this area).
>
> Does the macOS Terminal.app support the xterm mouse protocol?

Yes it does.

The clipboard problem is something unrelated. Terminal applications can
access the macOS clipboard via command line utilities pbcopy and
pbpaste. I'm using the package xclip for that, which is very simple to
use

  ;; Clipboard support in terminal Emacs using pbcopy/pbpaste.
  (use-package xclip :straight t
    :if (not (display-graphic-p))
    :config (xclip-mode 1))

Command-C, Command-V in Terminal.app are used by Terminal.app itself and
not by applications running in the terminal emulator. For example, to
copy shell output or paste something as shell input.

I don't think Terminal.app allows altering Command-V etc. so that Emacs
could use them. Other terminal emulators like iTerm allow doing that.

In summary, this is not a bug.

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]

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

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

[Gerd Möllmann]

Jared Finder <jared@finder.org> writes:

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

The Elpa package xclip uses that.

  ;; This package allows Emacs to copy to and paste from the GUI clipboard
  ;; when running in text terminal.
  ;;
  ;; It can use external command-line tools for that, which you may need
  ;; to install in order for the package to work.
  ;; More specifically, it can use the following tools:
  ;; - Under X11: `xclip' or `xsel' (https://xclip.sourceforge.net and
  ;;   https://www.vergenet.net/~conrad/software/xsel/ respectively).
  ;; - MacOS: `pbpaste/pbcopy'
  ;; - Cygwin: `getclip/putclip'
  ;; - Under Wayland: `wl-clipboard' (https://github.com/bugaevc/wl-clipboard)
  ;; - Termux: `termux-clipboard-get/set'
  ;; - Emacs: It can also use Emacs's built-in GUI support to talk to the GUI.
  ;;   This requires an Emacs built with GUI support.
  ;;   It uses `make-frame-on-display' which has been tested to work under X11,
  ;;   but it's not known whether it works under MacOS or Windows.

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]

On 2024-12-15 19:40, Gerd Möllmann wrote:
> Jared Finder <jared@finder.org> writes:
> 
>> 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.
> 
> The Elpa package xclip uses that.
> 
>   ;; This package allows Emacs to copy to and paste from the GUI 
> clipboard
>   ;; when running in text terminal.
>   ;;
>   ;; It can use external command-line tools for that, which you may 
> need
>   ;; to install in order for the package to work.

Thanks. I just tested xclip-mode from Elpa and it indeed works to get 
copy operations work with Terminal.app. I think the best path forward 
would be to just mention this package in the NEWS update as a workaround 
for folks using Terminal.app. We could also recommend using iTerm2 as a 
GPL'd alternative that properly supports copy. (Paste works fine because 
Terminal.app supports xterm bracketed pastes.)

Eli, does this sound good to you?

   -- MJF

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

[Eli Zaretskii]

> Date: Sun, 15 Dec 2024 21:16:16 -0800
> From: Jared Finder <jared@finder.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, Filipp Gunbin <fgunbin@fastmail.fm>,
>  74833@debbugs.gnu.org, shipmints@gmail.com
> 
> On 2024-12-15 19:40, Gerd Möllmann wrote:
> > Jared Finder <jared@finder.org> writes:
> > 
> >> 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.
> > 
> > The Elpa package xclip uses that.
> > 
> >   ;; This package allows Emacs to copy to and paste from the GUI 
> > clipboard
> >   ;; when running in text terminal.
> >   ;;
> >   ;; It can use external command-line tools for that, which you may 
> > need
> >   ;; to install in order for the package to work.
> 
> Thanks. I just tested xclip-mode from Elpa and it indeed works to get 
> copy operations work with Terminal.app. I think the best path forward 
> would be to just mention this package in the NEWS update as a workaround 
> for folks using Terminal.app. We could also recommend using iTerm2 as a 
> GPL'd alternative that properly supports copy. (Paste works fine because 
> Terminal.app supports xterm bracketed pastes.)
> 
> Eli, does this sound good to you?

It does (I think it should also be in PROBLEMS), but I wonder whether
we should disable xterm-mouse on Terminal.app (assuming we can detect
it).  It sounds like more people could bump into this tricky issue,
and relying on all of them read NEWS is too optimistic.

What are the downsides of turning this off for Terminal.app?  That's
what Emacs before 31 had, so it cannot be too bad.

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

[Ship Mints]

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

I use xterm-mouse under Terminal.app just fine as I rely only on Emacs
pasteboard integration via xclip. (I use clipetty when terminals support
osc52--there's no easy programmatic test for that which I'm aware of so I
set that up "by hand.") I don't think it is a good idea to blanket disable
xterm-mouse for macOS users.

FWIW, one can detect it via getenv "TERM_PROGRAM" when set to "Apple_Terminal".
I'd suggest this is an exercise for the user. In my configuration, I have
various things I configure based on if macOS and the terminal program; one
being Apple's Terminal.app, another being WezTerm, etc.

On Mon, Dec 16, 2024 at 11:37 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 15 Dec 2024 21:16:16 -0800
> > From: Jared Finder <jared@finder.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>, Filipp Gunbin <fgunbin@fastmail.fm>,
> >  74833@debbugs.gnu.org, shipmints@gmail.com
> >
> > On 2024-12-15 19:40, Gerd Möllmann wrote:
> > > Jared Finder <jared@finder.org> writes:
> > >
> > >> 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.
> > >
> > > The Elpa package xclip uses that.
> > >
> > >   ;; This package allows Emacs to copy to and paste from the GUI
> > > clipboard
> > >   ;; when running in text terminal.
> > >   ;;
> > >   ;; It can use external command-line tools for that, which you may
> > > need
> > >   ;; to install in order for the package to work.
> >
> > Thanks. I just tested xclip-mode from Elpa and it indeed works to get
> > copy operations work with Terminal.app. I think the best path forward
> > would be to just mention this package in the NEWS update as a workaround
> > for folks using Terminal.app. We could also recommend using iTerm2 as a
> > GPL'd alternative that properly supports copy. (Paste works fine because
> > Terminal.app supports xterm bracketed pastes.)
> >
> > Eli, does this sound good to you?
>
> It does (I think it should also be in PROBLEMS), but I wonder whether
> we should disable xterm-mouse on Terminal.app (assuming we can detect
> it).  It sounds like more people could bump into this tricky issue,
> and relying on all of them read NEWS is too optimistic.
>
> What are the downsides of turning this off for Terminal.app?  That's
> what Emacs before 31 had, so it cannot be too bad.
>

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

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

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 15 Dec 2024 21:16:16 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, Filipp Gunbin <fgunbin@fastmail.fm>,
>>  74833@debbugs.gnu.org, shipmints@gmail.com
>> 
>> On 2024-12-15 19:40, Gerd Möllmann wrote:
>> > Jared Finder <jared@finder.org> writes:
>> > 
>> >> 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.
>> > 
>> > The Elpa package xclip uses that.
>> > 
>> >   ;; This package allows Emacs to copy to and paste from the GUI 
>> > clipboard
>> >   ;; when running in text terminal.
>> >   ;;
>> >   ;; It can use external command-line tools for that, which you may 
>> > need
>> >   ;; to install in order for the package to work.
>> 
>> Thanks. I just tested xclip-mode from Elpa and it indeed works to get 
>> copy operations work with Terminal.app. I think the best path forward 
>> would be to just mention this package in the NEWS update as a workaround 
>> for folks using Terminal.app. We could also recommend using iTerm2 as a 
>> GPL'd alternative that properly supports copy. (Paste works fine because 
>> Terminal.app supports xterm bracketed pastes.)
>> 
>> Eli, does this sound good to you?
>
> It does (I think it should also be in PROBLEMS), but I wonder whether
> we should disable xterm-mouse on Terminal.app (assuming we can detect
> it).  It sounds like more people could bump into this tricky issue,
> and relying on all of them read NEWS is too optimistic.
>
> What are the downsides of turning this off for Terminal.app?  That's
> what Emacs before 31 had, so it cannot be too bad.

In my last reply to the OP I wrote 

  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.

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

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Filipp Gunbin <fgunbin@fastmail.fm>,
>   74833@debbugs.gnu.org,  shipmints@gmail.com
> Date: Mon, 16 Dec 2024 04:40:03 +0100
> 
> Jared Finder <jared@finder.org> writes:
> 
> > 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.
> 
> The Elpa package xclip uses that.
> 
>   ;; This package allows Emacs to copy to and paste from the GUI clipboard
>   ;; when running in text terminal.
>   ;;
>   ;; It can use external command-line tools for that, which you may need
>   ;; to install in order for the package to work.
>   ;; More specifically, it can use the following tools:
>   ;; - Under X11: `xclip' or `xsel' (https://xclip.sourceforge.net and
>   ;;   https://www.vergenet.net/~conrad/software/xsel/ respectively).
>   ;; - MacOS: `pbpaste/pbcopy'
>   ;; - Cygwin: `getclip/putclip'
>   ;; - Under Wayland: `wl-clipboard' (https://github.com/bugaevc/wl-clipboard)
>   ;; - Termux: `termux-clipboard-get/set'
>   ;; - Emacs: It can also use Emacs's built-in GUI support to talk to the GUI.
>   ;;   This requires an Emacs built with GUI support.
>   ;;   It uses `make-frame-on-display' which has been tested to work under X11,
>   ;;   but it's not known whether it works under MacOS or Windows.

It is not needed on Windows (at least the latest versions of it).

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

[Filipp Gunbin]

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.