bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74833: 31.0.50; Copy to OS clipboard doesn't work in macOS Terminal.


From: Eli Zaretskii
Subject: bug#74833: 31.0.50; Copy to OS clipboard doesn't work in macOS Terminal.app with xterm-mouse-mode enabled
Date: Mon, 16 Dec 2024 21:58:16 +0200

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]