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 #146 received at 74833 <at> debbugs.gnu.org (full text, mbox):

From: Ship Mints <shipmints <at> gmail.com>
To: Jared Finder <jared <at> finder.org>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, fgunbin <at> fastmail.fm, 74833 <at> debbugs.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: Thu, 19 Dec 2024 18:23:27 +0100

[Message part 1 (text/plain, inline)]

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 <at> finder.org> wrote:

> On 2024-12-18 09:50, Ship Mints wrote:
> > On Tue, Dec 17, 2024 at 1:32 PM Eli Zaretskii <eliz <at> 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
>

[Message part 2 (text/html, inline)]

Previous Next

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