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

Package: emacs;

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Jared Finder <jared <at> finder.org>
Cc: 74833 <at> debbugs.gnu.org, rms <at> gnu.org, gerd.moellmann <at> gmail.com,
 shipmints <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>, fgunbin <at> fastmail.fm
Subject: Re: bug#74833: 31.0.50; Copy to OS clipboard doesn't work in macOS
 Terminal.app with xterm-mouse-mode enabled
Date: Mon, 06 Jan 2025 13:25:31 -0500
> +(defconst xterm--auto-xt-mouse-allowed-names
> +  (mapconcat (lambda (s) (concat "^" s "\\>"))
> +             '("Konsole"
> +               "WezTerm"
> +               ;; "XTerm"   ;Disabled because OSC52 support is opt-in only.
> +               "iTerm2"     ;OSC52 support has opt-in/out UI on first usage
> +               "kitty")
> +             "\\|")

Sounds good, tho I'd use

    (concat "\\`" (regexp-opt '(...)) "\\>")

> +(defconst xterm--auto-xt-mouse-allowed-types
> +  (mapconcat (lambda (s) (concat "^" s "$"))
> +             '("alacritty"
> +               "contour")
> +             "\\|")

Same here (with \` and \')

> +  "Like `xterm--auto-xt-mouse-allowed-names', but for the terminal's type.
> +This will get matched against the environment variable \"TERM\".")

We should clarify if it's an "and" or an "or": if only one of
the two vars matches, is the feature enabled or not?

> @@ -907,7 +963,15 @@ xterm--init
>  
>    (when xterm-set-window-title
>      (xterm--init-frame-title))
> -  (when xterm-mouse-mode
> +  (when (and (not xterm-mouse-mode-called)
> +             ;; Only automatically enable xterm mouse on terminals
> +             ;; confirmed to still support all critical editing
> +             ;; workflows (bug#74833).
> +             (or (string-match-p xterm--auto-xt-mouse-allowed-types
> +                                 (tty-type (selected-frame)))
> +                 (and-let* ((name-and-version (xterm--query-name-and-version)))
> +                   (string-match-p xterm--auto-xt-mouse-allowed-names
> +                                   name-and-version))))
>      (xterm-mouse-mode 1))
>    ;; Unconditionally enable bracketed paste mode: terminals that don't
>    ;; support it just ignore the sequence.

- The above enables `xterm-mouse-mode` which will
  then proceed to *not* obey `xterm--auto-xt-mouse-allowed-*` on any
  further ttys used in the same session.

  IOW, I think the above test belongs in
  `turn-on-xterm-mouse-tracking-on-terminal` rather than here.

- Maybe instead of `xterm-mouse-mode-called` we should test

    (eq xterm-mouse-mode 'when-safe)

  or maybe rename the var to something more explicit like
  `xterm-mouse-mode-only-when-safe`.

- Of course, the previous code was also very weird:

    (when xterm-mouse-mode (xterm-mouse-mode 1))

  says to enable the mode, but only when it's already enabled?!


        Stefan





This bug report was last modified 111 days ago.

Previous Next


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