From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Duncan Findlay Newsgroups: gmane.emacs.devel Subject: Re: Set X primary selection with Emacs in xterm Date: Fri, 10 Jun 2022 11:10:50 -0700 Message-ID: References: <83y1yecjzx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22211"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 10 21:41:39 2022 Return-path: Envelope-to: ged-emacs-devel@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 1nzkVn-0005f7-Bz for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jun 2022 21:41:39 +0200 Original-Received: from localhost ([::1]:57858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nzkVm-0005Ew-1o for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Jun 2022 15:41:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nzj6a-0002mr-FT for emacs-devel@gnu.org; Fri, 10 Jun 2022 14:11:32 -0400 Original-Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]:37828) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nzj6Y-00028F-KF for emacs-devel@gnu.org; Fri, 10 Jun 2022 14:11:32 -0400 Original-Received: by mail-vs1-xe2c.google.com with SMTP id e20so6369750vso.4 for ; Fri, 10 Jun 2022 11:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xUwo68sKC3h3K/tOrU2AOBOJ6BAJQh0k8FDc29ddi1s=; b=EoT/zQaHX343I41GlZ2c8bR2alq/tJbLGIEidoBfsUNgcmS3cyPZdc5VDstHUdZxwY nBEcl7J2+35q4aygbhnJwfbEdHTahX6ODbdF0ZZzgb99+WrTGN7+joEDQz+ICEn6VsDy 4/zH8xyjJ4pfgwMFAaZquXGHTHzvc+59EctakvAYHyu8burppzQKLYdy1Vt2+qXKZev4 ntC0J9tBC3yKKenhz9GwJjSimf7tOq7/i2e2Z2Pwi4fk65q3HHhdKTByhqx7OoHSpzod LlJ3DEcm+7NfWWAeAn8PoXy5AeNbfjrVNFGwQa2XsuN7nNDiGwr/5LMCg39BRL85eouP nt6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xUwo68sKC3h3K/tOrU2AOBOJ6BAJQh0k8FDc29ddi1s=; b=IeEY9rNOct0upbczlqbVPCnKhMv0HnG0pebyObVhUb4+TK7ZVvnrUlhUSBYozssc46 8GYuZS5K8te0/6U7eRlwVehhN5ocd/UiFURbhM5ROczyDkRjRdrq3TNGZbNfTPtbnD0Q uTyabe9e8YfuSDdKycydDRO8t5brtRnvQfLr4U5fG1bgxrT0QcLAjJZIQkniAHvjm/et Vtj5hiteayxXxxpLFGeuwu7pi3lE4s2jK3SA31Tj+MzHP0Undge5s4ccklsoXpshGLOJ fMOgxoNSy3CMj7ByhAC9k6YcnB7XFqPCYPdeJJ2Pk6rTjJISawNgBGR8jyx8DrO5PW5a 2GIA== X-Gm-Message-State: AOAM533CzOGQeDhWen6FGkPYv6kJfOxSWxX22e9Bh+4R+OZDpwAIQiit GaNqAroG7F1f7oPnk0HAJsi5UQpA3C2Z4khMRonrPQb/5Q8Bmg== X-Google-Smtp-Source: ABdhPJwUGVTEEKouR0woCCOc/zMpgzobxljoO/iisrBwaI8tn3zBSOqo+eCLfreAQHvpIziZ4/tJ1s/Mziwxxer6fPA= X-Received: by 2002:a67:c081:0:b0:349:2d9a:2d6b with SMTP id x1-20020a67c081000000b003492d9a2d6bmr21405938vsi.10.1654884689019; Fri, 10 Jun 2022 11:11:29 -0700 (PDT) In-Reply-To: <83y1yecjzx.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::e2c; envelope-from=duncf@google.com; helo=mail-vs1-xe2c.google.com X-Spam_score_int: -175 X-Spam_score: -17.6 X-Spam_bar: ----------------- X-Spam_report: (-17.6 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 10 Jun 2022 15:39:05 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:291007 Archived-At: On Thu, Jun 2, 2022 at 11:56 PM Eli Zaretskii wrote: > Thanks. I think we should solve this differently. I don't think it's > a good idea to call arbitrary Lisp from input-processing loop in > keyboard.c, anymore than we already do (which is already too much, > IMNSHO), especially if we envision advices for that code. > > We should instead modify the condition in command_loop_1 to support > terminals that can set GUI selections. terminal-parameter is a > primitive written in C, so command_loop_1 could call it directly (it > should also pay attention to the defcustom described below). I considered this, but given that we're making the same decision in lisp/simple.el (deactivate-mark) using display-selections-p, the benefits of sharing an implementation seemed compelling. I see your point about wanting to minimize lisp in the command loop. Can we just port display-selections-p to C and use it from both places, or will that break things? > > The second patch changes `(display-selections-p)' to return true > > under xterm with the setSelection feature enabled. > > This part is mostly fine, but it should be augmented to resolve the > issues below. > > > I don't know if this second patch can be submitted as is. It may break > > existing users. tmux, for example, removes the selection indicator > > from OSC 52 codes, so if emacs writes to both CLIPBOARD and PRIMARY > > selections, both updates will go to the same buffer on the user's > > side. I've filed https://github.com/tmux/tmux/issues/3192 with tmux. I > > haven't tested GNU screen. FWIW, the tmux bug is now fixed. > > This patch will also lead to extra data being sent to the user's > > terminal which they may not need or want. It might be wise to only > > send OSC 52 codes for primary selection if the user actually has a > > primary selection buffer, but I'm not sure the best way to do that. > > I'd appreciate some guidance here, or if somebody more experienced > > wants to take this on, that'd be most appreciated. > > I think TRT here is to provide a defcustom, so that users could > disable this feature if it causes more trouble than it's worth. With > time, perhaps we will collect enough user experience to come up with > the default value that makes the most sense on most supported systems; > for now setting the X selection could just be disabled by default. My initial resistance to a defcustom was because this feature already requires xterm support for setSelection, which is already somewhat rare, and it's already controlled by `select-active-regions'. Without a new defcustom, it can be turned off with: (add-hook 'terminal-init-xterm-hook (lambda () (setq select-active-regions nil))) But I accept the feedback that this is not discoverable, and people want to avoid surprises, so having a defcustom that's off by default makes sense. I'll upload a new version of the patch to the tracker shortly. > > > --- a/lisp/frame.el > > +++ b/lisp/frame.el > > @@ -2164,6 +2164,9 @@ display-selections-p > > (not (null dos-windows-version)))) > > ((memq frame-type '(x w32 ns pgtk)) > > t) > > + ((and (memq frame-type '(t)) > > + (eq (terminal-parameter nil 'xterm--set-selection) t)) > > + t) > > This is unnecessarily strict: there should be no need to test > frame-type, since any frame type could arrange for this parameter when > it supports selections. In practice, are there other frame types? Is it reasonable to set terminal-parameter for other frame types? Thanks Duncan