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
Reported by: Filipp Gunbin <fgunbin <at> fastmail.fm>
Date: Thu, 12 Dec 2024 17:56:02 UTC
Severity: normal
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #134 received at 74833 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Ship Mints <shipmints <at> gmail.com>
>> Date: Mon, 16 Dec 2024 15:07:25 -0500
>> Cc: fgunbin <at> fastmail.fm, gerd.moellmann <at> gmail.com, jared <at> finder.org,
>> 74833 <at> 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).
This bug report was last modified 112 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.