From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ship Mints Newsgroups: gmane.emacs.bugs 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 14:20:40 -0500 Message-ID: References: <8634iszpa5.fsf@gnu.org> <86y10ky9wf.fsf@gnu.org> <86wmg4xd2u.fsf@gnu.org> <86y10jwmsb.fsf@gnu.org> <86ldwiwvjc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000050304f0629681667" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11628"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , Eli Zaretskii , Jared Finder , 74833@debbugs.gnu.org To: Filipp Gunbin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 16 20:23:20 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tNGga-0002s7-2p for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Dec 2024 20:23:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tNGgK-0005Ie-MN; Mon, 16 Dec 2024 14:23:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tNGgI-0005IT-WE for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 14:23:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tNGgI-0004J8-NP for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 14:23:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=lvzJxFs+0BT2HwpNuf+pgiaUg/tvCmOYXQV25T8u5Hs=; b=FK9GaY3F3+YlDgXlc9Ra8L7/arWSBFdBKyiGSk/xPCeNYU0QEQ8eCzwTfVmL8tJZketDkVYw6oqoxD2Cx6I+QU64i0rrRKvCqLbPXJgebiVw0eqg4E/1ad0PesPcwrRA/AgYL7tioV3VL+j5HQYfswpvW+rJ0Iq8wjNmEzohDwy1258lgqxZW3OwoOdHU8Qss0btwfaUgekZnmNCRADoJBZnnHVWBlQHP+vxzmEl7YEeJceGnku7wgX/bLjXYLXAKzvHKvMmKhD/6LR4YgtZpRrlYV0TPYyAmaIY3s+pEZ98nkDO8S7TBpJ4R9Cpcmf4gkedfCqyCFdkvLjwtkhNJA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tNGgI-0004JU-HN for bug-gnu-emacs@gnu.org; Mon, 16 Dec 2024 14:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ship Mints Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Dec 2024 19:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74833 X-GNU-PR-Package: emacs Original-Received: via spool by 74833-submit@debbugs.gnu.org id=B74833.173437695616526 (code B ref 74833); Mon, 16 Dec 2024 19:23:02 +0000 Original-Received: (at 74833) by debbugs.gnu.org; 16 Dec 2024 19:22:36 +0000 Original-Received: from localhost ([127.0.0.1]:56264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNGfr-0004IT-8w for submit@debbugs.gnu.org; Mon, 16 Dec 2024 14:22:35 -0500 Original-Received: from mail-qv1-f52.google.com ([209.85.219.52]:43395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tNGfp-0004IC-Eb for 74833@debbugs.gnu.org; Mon, 16 Dec 2024 14:22:34 -0500 Original-Received: by mail-qv1-f52.google.com with SMTP id 6a1803df08f44-6d92cd1e811so51610526d6.1 for <74833@debbugs.gnu.org>; Mon, 16 Dec 2024 11:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734376888; x=1734981688; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lvzJxFs+0BT2HwpNuf+pgiaUg/tvCmOYXQV25T8u5Hs=; b=S4ZkUJJxwJ4zbJERa5nleMA2N2s6GrGUYo2ZLem7LwJhOBkkw4Ya0LUJ9pb15UtwKU IpwC5JFWHcuIA/rkTEcw85PAW2mCenswx68L3mH6ylJyXKAKHllaoZqditA9+Fz3j7NS 2iAbp3UY0W83jax9yIunubwZW7/klIatzBlqXWTdUc0MTKuPXLm3ytR2hiupRXF+reP9 0e5Y828JHulEjp62PG6NWTP4snH8wZ/9RxwahN9CfYR7SvB4mS9J8VnvzvjVnRhmBbNO 27R2j7eOOpOltQoTqxThdwEIVV51KSLAz8QGkrzLuAz5DAM2LN08Ri0csFlzSpXBtGMR LWig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734376888; x=1734981688; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lvzJxFs+0BT2HwpNuf+pgiaUg/tvCmOYXQV25T8u5Hs=; b=QUXI1sWSftuwkGlkmN83C1m0a5XDrPOG4ijweKfRLMr7Y067yG/eEiTvVgpJRmekf/ L49h7viKDSDuoI1oLsTDU9xMLe3M/5jncNBhLSezeQSshHUA236r/BVBYsnChz15fpdw YH13/+SdyKC8HqtkjIr3r5mEe/LvidivpWxkWyHNGRG3B7knJzqLxUNXeH/GJtXihcur NHoOlJLdF/nzdsJeIjFYwIjE+AADioGXclU5O0wc9OMMnn8DJ3j6yC7xOFGz++fxt4ss u8QASIirLTn0KJJoMJRn01s+JFqHYB3ULryIbZzCKgXBYpDp9aScRXVHqWuyHLn9FzHW ApMA== X-Forwarded-Encrypted: i=1; AJvYcCWQbuxwQnco0+onmye39JmNEBPm35guJQT6IH9a+t825tarwfQiamalsAYoG+BjYSxfywa/AQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwJZtlkqOQjm7z8kWJuPjh+leoV72GtUi5Lg2h9+I0NxO+4XL+W SZFnmvNmIO4c6KrV6Fc+EzKhcU8dBx59ecnOMlRwLnbgmA/SGMW9htaPMkcU+XpLuyxdPUNu1Ce fk9zNsMgxXSJ300WUzFnWSpNbcpc= X-Gm-Gg: ASbGnctxAcNCvB58Orm9YFUXuV9T52v+h8UgEz152Xz/ie+7HsWBFn8wA5VUr0zZGCQ I52Rdc/cbhJjZz0xlg2A5c0/esUlhPhr7bZkO9g== X-Google-Smtp-Source: AGHT+IFimvm5QfLk0s4ofahnGdnwKq3YSMcMY4sM5EIFFJ5gX0kafyYTGK/989ekXNlAodbdogUNpHsOktXnOg+uryU= X-Received: by 2002:ad4:5aea:0:b0:6d8:e838:6cc8 with SMTP id 6a1803df08f44-6dcf4c849f0mr8181636d6.17.1734376887954; Mon, 16 Dec 2024 11:21:27 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:297218 Archived-At: --00000000000050304f0629681667 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. 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. On Mon, Dec 16, 2024 at 2:09=E2=80=AFPM Filipp Gunbin = wrote: > On 16/12/2024 18:30 +0100, Gerd M=C3=B6llmann wrote: > > > Filipp Gunbin writes: > > > >>> Terminal.app's Command-C can only copy a selection that the app knows > >>> about. > >> > >> Not really - with xterm-mouse-mode disabled (and with "Allow mouse > >> reporting" ticked in Terminal.app menu), mouse selection in Terminal.a= pp > >> is not related to Emacs selection, and copy / paste works. > > > > What I meant with my sentence is that the selection Emacs shows and the > > selection Terminal.app shows and uses are not related to each other. > > Maybe that's a cause of confusion, I don't know. > > > >> > >>> If the mouse is used by an app like Emacs (Terminal.app's > >>> Settings/Report ....)) the user tells Terminal to let the app use the > mouse. > >>> I find it little surprising that when Terminal.app does that, it > doesn't > >>> use the mouse itself to make a selection it could then copy. > >> > >> It does, although that's Terminal.app's "own" selection, not Emacs's. > >> > >>> Do Command-A Command-C and see what happens. > >>> > >>> Or use Command-R to toggle the mouse reporting setting on the fly. > >>> > >>> Or use xclip in Emacs. > >>> > >>> Please don't disable xterm-mouse for this. > >> > >> Again, it turns out that the new default leads to copy not working at > >> all, while with previous default you could make selection in > >> Terminal.app (it's not reflected in Emacs) and then copy. Paste works > >> in both cases. It still looks to me that the old default is better. = If > >> you enable xterm-mouse-mode, then perhaps you should also use xclip, n= ot > >> just the mode itself. > > > > Mouse support by default is an important feature, IMO. It makes the men= u > > bar usable, or in a future Emacs containing tty child frames tooltips > > can be shown. Not to mention setting point and what else. > > > > What's the positive effect of turning mouse support off by default? > > Command-C works for users who haven't set up terminal Emacs well enough > > that they could use M-w, plus in addition don't know Terminal.app well > > enough to know about Command-R or Fn + mouse. > > My point is exactly that Command-C _doesn't work_ for them, with current > defaults (xterm-mouse-mode on in Emacs; "Allow mouse reporting" ticked - > which is the default for a new Terminal.app tab, at least here). > > > I think it's best if we simply agree to disagree. > > I don't think we disagree much, I see the value of xterm-mouse-mode > (although I like "just text" on tty, no menus etc.), the only thing > which concerns me (and is the reason for this bug) are "half-broken" > defaults. We're discussing whether to disable xterm-mouse-mode only in > Terminal.app, not everywhere. > --00000000000050304f0629681667 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 differe= nt than Command-C. That Terminal.app supersedes Emacs is not an Emacs probl= em, it's Terminal's problem. This feels like documentation issue no= t something to cure with default Emacs configuration.

Other terminal applications like i= Term or WezTerm can be programmed similarly to pass through all keys that y= ou want them to with modifiers, but by default, they don't. These can&#= 39;t be Emacs's problem either. Same with Emacs run via ssh with tmux o= n the other side. That's a "default" set of features offered = on many systems and their configuration is not Emacs's problem.

This issue sounds li= ke 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.

On Mon, Dec= 16, 2024 at 2:09=E2=80=AFPM Filipp Gunbin <fgunbin@fastmail.fm> wrote:
On 16/12/2024 18:30 +0100, Gerd M=C3=B6llmann= wrote:

> Filipp Gunbin <fgunbin@fastmail.fm> writes:
>
>>> Terminal.app's Command-C can only copy a selection that th= e app knows
>>> about.
>>
>> Not really - with xterm-mouse-mode disabled (and with "Allow = mouse
>> reporting" ticked in Terminal.app menu), mouse selection in T= erminal.app
>> is not related to Emacs selection, and copy / paste works.
>
> What I meant with my sentence is that the selection Emacs shows and th= e
> selection Terminal.app shows and uses are not related to each other. > Maybe that's a cause of confusion, I don't know.
>
>>
>>> If the mouse is used by an app like Emacs (Terminal.app's<= br> >>> Settings/Report ....)) the user tells Terminal to let the app = use the mouse.
>>> I find it little surprising that when Terminal.app does that, = it doesn't
>>> use the mouse itself to make a selection it could then copy. >>
>> It does, although that's Terminal.app's "own" se= lection, not Emacs's.
>>
>>> Do Command-A Command-C and see what happens.
>>>
>>> Or use Command-R to toggle the mouse reporting setting on the = fly.
>>>
>>> Or use xclip in Emacs.
>>>
>>> Please don't disable xterm-mouse for this.
>>
>> Again, it turns out that the new default leads to copy not working= at
>> all, while with previous default you could make selection in
>> Terminal.app (it's not reflected in Emacs) and then copy.=C2= =A0 Paste works
>> in both cases.=C2=A0 It still looks to me that the old default is = better.=C2=A0 If
>> you enable xterm-mouse-mode, then perhaps you should also use xcli= p, not
>> just the mode itself.
>
> Mouse support by default is an important feature, IMO. It makes the me= nu
> bar usable, or in a future Emacs containing tty child frames tooltips<= br> > can be shown. Not to mention setting point and what else.
>
> What's the positive effect of turning mouse support off by default= ?
> Command-C works for users who haven't set up terminal Emacs well e= nough
> that they could use M-w, plus in addition don't know Terminal.app = well
> enough to know about Command-R or Fn + mouse.

My point is exactly that Command-C _doesn't work_ for them, with curren= t
defaults (xterm-mouse-mode on in Emacs; "Allow mouse reporting" t= icked -
which is the default for a new Terminal.app tab, at least here).

> I think it's best if we simply agree to disagree.

I don't think we disagree much, I see the value of xterm-mouse-mode
(although I like "just text" on tty, no menus etc.), the only thi= ng
which concerns me (and is the reason for this bug) are "half-broken&qu= ot;
defaults.=C2=A0 We're discussing whether to disable xterm-mouse-mode on= ly in
Terminal.app, not everywhere.
--00000000000050304f0629681667--