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

Previous Next

Full log

Message #191 received at 74833 <at> debbugs.gnu.org (full text, mbox):

From: Jared Finder <jared <at> finder.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 74833 <at> debbugs.gnu.org, fgunbin <at> fastmail.fm,
 shipmints <at> gmail.com, rms <at> gnu.org
Subject: Re: bug#74833: 31.0.50; Copy to OS clipboard doesn't work in macOS
 Terminal.app with xterm-mouse-mode enabled
Date: Sat, 28 Dec 2024 21:16:28 -0800

On 2024-12-28 00:54, Eli Zaretskii wrote:
>> Date: Fri, 27 Dec 2024 23:08:27 -0800
>> From: Jared Finder <jared <at> finder.org>
>> Cc: shipmints <at> gmail.com, rms <at> gnu.org, gerd.moellmann <at> gmail.com,
>>  fgunbin <at> fastmail.fm, 74833 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.