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
>