From unknown Tue Jun 17 20:21:37 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#64423 <64423@debbugs.gnu.org> To: bug#64423 <64423@debbugs.gnu.org> Subject: Status: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections Reply-To: bug#64423 <64423@debbugs.gnu.org> Date: Wed, 18 Jun 2025 03:21:37 +0000 retitle 64423 29.0.92; save-interprogram-paste-before-kill doesn't prevent = streaming large selections reassign 64423 emacs submitter 64423 sbaugh@catern.com severity 64423 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 02 10:13:18 2023 Received: (at submit) by debbugs.gnu.org; 2 Jul 2023 14:13:18 +0000 Received: from localhost ([127.0.0.1]:60899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFxpG-0004qz-1U for submit@debbugs.gnu.org; Sun, 02 Jul 2023 10:13:18 -0400 Received: from lists.gnu.org ([209.51.188.17]:41868) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qFxpC-0004qq-Sc for submit@debbugs.gnu.org; Sun, 02 Jul 2023 10:13:17 -0400 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 1qFxp9-0004UF-85 for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 10:13:12 -0400 Received: from s.wrqvtzvf.outbound-mail.sendgrid.net ([149.72.126.143]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qFxp5-0007wA-3T for bug-gnu-emacs@gnu.org; Sun, 02 Jul 2023 10:13:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:mime-version:to:content-type:content-transfer-encoding: cc:content-type:from:subject:to; s=s1; bh=ffWokBm66635tFBEInreZWxDY4UMpGw0EbqNe6Thwk8=; b=pbc5X44u+sW4kYKTM3lQtjxnYy1P7IVe56QSdVOOt5TAPY8CR52RR38ucc5TGGQX5ypH 43dISEz0IzPCrfZioaqzUeuJvZjaqpFV5aBalDgcq2JyIRbHyyRowXF9mBlJTnmmL4me9h mii1Efl+GJDc1oUbK5BQ6DDC8yaZET1oMcnjxEJ/ASyZ8Kt/kXUN+QUHTuVJtmoBjdbedH JtlvoCaMEmnQn4TGtJ6qKLTnO/Uj7nqOGsjsC/KTgPWMZuPjEQ0aUxNXjhfZsf3RyyFBVp vlXc3m3NVCT0LGzsec2Q7vss8kbo6/ejF3D8mF9n32o3dyAjn5MeizJIa97hAeCg== Received: by filterdrecv-84b96456cb-5hl7m with SMTP id filterdrecv-84b96456cb-5hl7m-1-64A185F0-8 2023-07-02 14:13:04.463652053 +0000 UTC m=+4545288.432399541 Received: from earth.catern.com (unknown) by geopod-ismtpd-14 (SG) with ESMTP id 2ZNT37E4QG64EadP4FDFbA for ; Sun, 02 Jul 2023 14:13:04.279 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver= Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 9F19060087 for ; Sun, 2 Jul 2023 10:13:03 -0400 (EDT) From: sbaugh@catern.com Subject: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections Date: Sun, 02 Jul 2023 14:13:04 +0000 (UTC) Message-ID: <875y72ieq8.fsf@catern.com> MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbI7nUtZuMQcihpgPKx30C?= =?us-ascii?Q?OfyzI59CKA8X7l=2FxlvLInmt9xVlz24Gis31XQKp?= =?us-ascii?Q?=2FwlHrx7TAmoziTN28fEwtd5RKBOgDdcADrTLZip?= =?us-ascii?Q?dO9LnrAsaps4wN78TsKtCz9X9TXFfkhit3R8efX?= =?us-ascii?Q?+ry9heKqdFop6LSCBPFDxpG81nnptw3YE2Q=3D=3D?= To: bug-gnu-emacs@gnu.org X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=149.72.126.143; envelope-from=bounces+21787432-3678-bug-gnu-emacs=gnu.org@em8926.catern.com; helo=s.wrqvtzvf.outbound-mail.sendgrid.net X-Spam_score_int: -7 X-Spam_score: -0.8 X-Spam_bar: / X-Spam_report: (-0.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) 1. emacs -Q under X, preferably X forwarded over ssh to make things slower. 2. (setq save-interprogram-paste-before-kill 2000) (or any other integer) 3. Copy some very large data in another X client, so the selection is very large. 4. (kill-new "foo") 5. Observe Emacs hanging as it receives the entire large data from the selection owner, and then after receiving it all, discards it because it's more than 2000 bytes. Solution: receive_incremental_selection in xselect.c should support a cap on the size of the selection it receives and truncate (or discard, returning nil?) the selection if it's larger than that. And setting save-interprogram-paste-before-kill to a numeric value should activate this cap. In GNU Emacs 29.0.92 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw3d scroll bars) of 2023-07-01 built on earth Repository revision: b179926388ee76f7b3304535a7189f89bd7c7f8c Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: NixOS 22.11 (Raccoon) Configured using: 'configure --with-x-toolkit=lucid --with-tree-sitter' Configured features: CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XAW3D XDBE XIM XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Help Minor modes in effect: TeX-PDF-mode: t pixel-scroll-precision-mode: t envrc-global-mode: t envrc-mode: t global-git-commit-mode: t magit-auto-revert-mode: t shell-dirtrack-mode: t server-mode: t windmove-mode: t savehist-mode: t save-place-mode: t tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tab-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t isearch-fold-quotes-mode: t context-menu-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t buffer-read-only: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: /home/sbaugh/.emacs.d/elpa/transient-0.3.7/transient hides /home/sbaugh/src/emacs/emacs-29/lisp/transient Features: (completion nndoc gnus-dup mm-archive debbugs-gnu debbugs-compat debbugs soap-client rng-xsd rng-dt rng-util xsd-regexp debbugs-browse octave semantic/symref/grep semantic/symref semantic/util-modes semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local cedet org-archive org-attach org-agenda org-capture display-line-numbers ibuffer ibuffer-loaddefs tabify em-tramp em-rebind em-smart em-unix em-term term ehelp em-script em-prompt em-ls em-hist em-pred em-glob em-extpipe em-cmpl em-dirs esh-var em-basic em-banner em-alias esh-mode eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util goto-addr man cus-theme eieio-custom xwidget magit-bookmark bookmark wid-browse tree-widget icon conf-mode descr-text cus-edit pcmpl-unix pcmpl-gnu shadow emacsbug misc dabbrev cl-print emacs-news-mode tex-info tex texmathp texinfo texinfo-loaddefs bug-reference org-element org-persist org-id org-refile avl-tree oc-basic ol-eww eww xdg url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview doc-view image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi org org-macro org-pcomplete org-list org-footnote org-faces org-entities noutline outline ob-python python ob ob-tangle org-src ob-ref ob-lob ob-table ob-exp ob-comint ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys oc org-loaddefs cal-menu calendar cal-loaddefs org-version org-compat org-macs etags fileloop generator find-dired pulse color js cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs grep vc-hg vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view vc nix-mode nix-repl nix-shell nix-store nix-log nix-instantiate nix-shebang nix-format nix rust-ts-mode c-ts-common sh-script smie treesit executable dired-aux dired-x tramp-archive tramp-gvfs tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat cus-start cus-load pixel-scroll cua-base misearch multi-isearch vc-git vc-dispatcher sort smiley gnus-cite mail-extr textsec uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check qp gnus-async gnus-bcklg gnus-ml disp-table nndraft nnmh nnfolder gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig nntp gnus-cache gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec gnus-int gnus-range gnus-win gnus nnheader range wid-edit timezone parse-time iso8601 mule-util jka-compr eglot external-completion array jsonrpc ert pp ewoc debug backtrace find-func xref flymake-proc flymake warnings icons compile project network-stream url-http url-gw nsm url-cache url-auth face-remap ffap shortdoc desktop frameset help-fns radix-tree lui-autopaste circe advice lui-irc-colors irc gnutls lcs lui-logging lui-format lui tracking shorten thingatpt flyspell ispell circe-compat agda2 envrc inheritenv page-ext magit-extras magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff diff-mode easy-mmode git-commit rx log-edit message sendmail yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log magit-core magit-autorevert autorevert filenotify magit-margin magit-transient magit-process with-editor shell pcomplete comint ansi-osc ring server ansi-color magit-mode transient cl-extra edmacro kmacro help-mode format-spec magit-git magit-section magit-utils crm dash windmove modus-vivendi-theme modus-themes pcase savehist saveplace finder-inf auctex-autoloads tex-site circe-autoloads csv-mode-autoloads cyberpunk-theme-autoloads debbugs-autoloads eat-autoloads envrc-autoloads ggtags-autoloads graphviz-dot-mode-autoloads htmlize-autoloads inheritenv-autoloads magit-autoloads git-commit-autoloads mentor-autoloads async-autoloads nix-mode-autoloads magit-section-autoloads dash-autoloads notmuch-autoloads rust-mode-autoloads transient-autoloads url-scgi-autoloads vundo-autoloads info with-editor-autoloads xml-rpc-autoloads package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 1334240 144878) (symbols 48 62872 2) (strings 32 278128 12807) (string-bytes 1 11041307) (vectors 16 132517) (vector-slots 8 2850991 257159) (floats 8 749 666) (intervals 56 83547 2259) (buffers 984 140)) From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 02 22:36:17 2023 Received: (at 64423) by debbugs.gnu.org; 3 Jul 2023 02:36:17 +0000 Received: from localhost ([127.0.0.1]:32973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qG9QH-0001UT-FH for submit@debbugs.gnu.org; Sun, 02 Jul 2023 22:36:17 -0400 Received: from sonic306-22.consmr.mail.ne1.yahoo.com ([66.163.189.84]:34158) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qG9QD-0001U8-Au for 64423@debbugs.gnu.org; Sun, 02 Jul 2023 22:36:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688351766; bh=CmE4MxfrouYeRgyYIVLvMZrKirlfMtT/bglBkF//hps=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=r81Rpnp3LI3pJhMtvehaZ0k547GiZcg/mCiz/jVqCw/xfsRJkorMM4ugF+TQhG/OoohtQbUA1Sr7Lbo+0tn5iMm1U25q5brNMhD6347N/8UT+hSxdbKi/6niCaA4lt0y7p73fJfVwFBdcH+TTcHTknW4bN8+/NqDq2ojH3vWBF9c3wFqW7ZUk4ndUQCcr7BVu/9PRzpMj/8HNO9OFsjY91MHumRdwkeqIOMaagsEWLwC6TM1owS1bIluGWjf99tx+sappk+q08S9b2Ytivy9as+bHtslL/Ki3Jgu840AzDHEGOSat2g1LqntJcjEU2YSj/jX1eXR+Jqy3/trUaXgbQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688351766; bh=7/otzJfX8FMZ1juwUA9nuwIlqmVPTRkapKd+KgYuWGE=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=B+M+/6s6ge6aNmZA8sL/VgcStDm2jz503OL37Qrvwyaho7PLuoGW6oGxCs9fB7WVRBTJUWwqpxVAP8g/qQqM6/oBclm2GRYv2OQiqH2lgNFmeHKumqymn3Z1bMApCn5picZ197hzh8UYKgZNI+5Fcm3ov8eh2NvaF2Xo3OKv2qrmWvQCDewwHSngot0qOK+6XwhMhTTy0Z0jwRiDoK8GBKNj8TMU2oOw57/+78rc3+oc+RPLXcBDcKC9uO4KEed9VjfiSneFM1RdJaBPZbPX6zTlTw+KQUsuIzghjk+dajVqrl+/sSWQchvpHnwK7lmhy+BmdFnwj9r09HSncFfZZA== X-YMail-OSG: bj9.nEEVM1ml4w2xyW0hjWjZaI6Uh3KkYjI4gMflqSaBUMcRHzmE7Ko1gISAd6i o7zLmXzmlsjszugcHLexX.WULWpQA2zruV1yjrZARsHFnO9paIslwRncjjjQKlkYeyMC0FB0VgF0 ywqxA2B1XkXOZvcUpFfRmkipUxDTjAZqM.H9SNbLwZSR90pKruPQiBQ4p3qzMzNZ9au3gFxXZIso 2LeDyokkdKT8JOfg8Oet5XqKxGpINYgaIGNtDVttqbLnrmkABdCNec4SxoMykPYmShFa0QSNJGcw S13QqFASdHJMKITj.xkWhdZ5k0RjiwkfOc5ZzGqOG6c_s7UPM80GQ4ejrF_R85WYscxDOBPX1Ouc tU5tWh3ts8mHwBe7fAnN1XTo5l1j49Uxz5YWhn5PUKS.kcQE.9YOj9kJFtbq0GXxPq1B0S5u.vgj iw3Nf1oS0MlOjaTFYz9t5cULbv3BDPyYcddCdFj6YGeBvbfnGP9gmxanBS9HvKvQFY.5vCdwwKB. RZ0ROfnwQX2nsBKCSVh5nbYPREHRbg9HUJQ5yfQK6yZnLbqkO8vC2FEmuXNt8rnrTQc5v.j.bLtA QK3IP33SQtCCBEmXU32x8m55AakNd788_B8lGsOfM8VM.qQzGLBhkzxchBprfGHKn4QRqn0cq_vZ UfQ_u0OLdvxYRIj2Wp.eFdLx3pgQLEDhaANRGkpUEsWgoT3TqmpubCNuqvjswn9T1CKXt5H.7XMr 5F0C_ftowm5VyObY5.YPBE1xDUibW.i1pyOFtIek8Ur29ZwUoXDtDxAH8Tj7w.VV.rbtWobihpsX F9m4VxkelmF2eSJtos05KnguBWBr66RhrQMiyDutQ1UC2EIli4fBYWcHt49vjg8BujySg8mwG4w_ _E9zdk.dXmmWub_F0xrhA8HcQ4qKqBQSrnZhwo8zrc3W7td2dObRRcjWyl3TsT_QD.niyKcEzj9Z TRSEqX2WrApClkwQrbXH2HPX7IVnxtqi5TeeVA3TuIyEJu3k7XRL5IdvpSPqoblbzGwxt0HqeDY5 p9rBD1UvizSj3ND8OT59kXikxJ1Ck4_5KqJDyF5arkfuwbWkenpzQVVJSqpENybw.KHjqC7EaCe9 US.wC7v4MB1l55jA0vV49VMX7VEZFyBf_eB7qxd9O4pUNwmti1eSnF2v8f_Iw_EIz2Q15YDw8s1B BmaxayW5wgdcb.SVeeZgqmWcJ5K8XrZOWjiadiXSs9fwm_tJPRwB1YgyUzzFJtT2wS8eco_fWBXt K4Ey.msm_ncyNI8rlTJEPjUyZGlNj45qqngeuab5Vj7WsBm.Cg0v3UPDhBs9hF06r0YB5PfwStGj sXe6ijT.oHrQ3milJM1XaXB9ATGvJ1g0PDCbv7qTZpx8h0KVV_97iQja_.SZQYlv_1nlPrYBzFpV RmKDXnqatajtmYccUqJigHAsaKaa0B4U2ara26.3OyQq5RUlMSiqFmrjwK98XXe8zj5K7SoT7NTr xCwEEZ_cJ1ZdjSeZsPRACTTKWyReRo3qf9TmettevxadVT1HwgHRNSjQFoEilgTN2rJoB6KSsNhy srQjmr8b56VLEl8yQwjX39qWbszk1CJJ3GXJ8okoimNFk65M_PtgOcknJfcHg5r81BmBq0wFExSd h2pKdUIVtYL2VEgOtyDRI3.SAXO_oVze8LEh2Fo4t.Mtc0liqUhki5sD5Cv1Bb_i454malqgQ0lP NvmRX_TygKYWcSU1_b_lHXtm_LbXhtaoWQcEP4o2E1M_mRJdCmeHrOCceRu9r_.W70zrouDo64oB BhMEoec6gsltFnZVQvpdm.Izsw44M2_f0wqWtEforlUxeOLISfDQhaFz0TSBlIYBwSDPsNLHFPHu hll1FkwwS1ECQ4CWVpLOojrWt8J.tEN4NUWNbnY8r4YXArQ_geUmhLUUE_KFUVgqCXHIqTM3IZI0 wdUNXQe.d3djSi3DgLfRadsMZJqb7KatY8alJG0QMbxtu5bqO7Rx2hPdri4g9mG2X6sSpESNtdAr czmIw2fABJJPOHKhDe7DQZZnlUy.9lecV7L.i61w1MPBJsLPGvCfV3W8VDeuReBI5o5HvAdYqbWA XKsuMZbt7FCH_DSI8vInbPTxGdtqsCD0JmskxOsMDe3CrHbrD5m34AV4sToBKtZ57R1_LdWxADYu 0zeKeliOI.tsZENpVd68Whug5UfBz3_WSVzo9nHohOJ3rwkOhoSwJ__AgMZIPGWnQu4zkKcOMYY3 LP8_a77NRtqnrCu.pS_r_a8gI5ifmndSsh7XdISYByBTaXsrC0al5PM6nejtFuHjR X-Sonic-MF: X-Sonic-ID: fc6f2ac6-4200-4fdc-b6cf-2df6146d777e Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Mon, 3 Jul 2023 02:36:06 +0000 Received: by hermes--production-sg3-67fd64777-szq9p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9c47b52b683a7bb4b4a2748f2e0b5b5a; Mon, 03 Jul 2023 02:35:59 +0000 (UTC) From: Po Lu To: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <875y72ieq8.fsf@catern.com> (sbaugh@catern.com's message of "Sun, 02 Jul 2023 14:13:04 +0000 (UTC)") References: <875y72ieq8.fsf@catern.com> Date: Mon, 03 Jul 2023 10:35:55 +0800 Message-ID: <87cz193eno.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1586 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) sbaugh@catern.com writes: > 1. emacs -Q under X, preferably X forwarded over ssh to make things slower. > 2. (setq save-interprogram-paste-before-kill 2000) (or any other integer) > 3. Copy some very large data in another X client, so the selection is > very large. > 4. (kill-new "foo") > 5. Observe Emacs hanging as it receives the entire large data from the > selection owner, and then after receiving it all, discards it because > it's more than 2000 bytes. > > Solution: receive_incremental_selection in xselect.c should support a > cap on the size of the selection it receives and truncate (or discard, > returning nil?) the selection if it's larger than that. And setting > save-interprogram-paste-before-kill to a numeric value should activate > this cap. This is not a bug because you can quit while Emacs is waiting for selection data to arrive from the owner. The ICCCM provides no means for the requestor to terminate an incremental selection transfer before it completes, and owners may become confused if Emacs abruptly stops responding to their property changes while a transfer is in progress. Emacs should avoid doing so unless the user explicitly quits (pointing to a problem with the selection owner anyway.) Additionally, the way we deal with potentially long-running data transfer operations in Emacs is not to apply a limit on the size of the data being transferred, but to make quitting possible within those transfers. What may be slow for you can in fact be perfectly acceptable for others who are connected to their X servers through faster connections. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 03 08:46:47 2023 Received: (at 64423) by debbugs.gnu.org; 3 Jul 2023 12:46:47 +0000 Received: from localhost ([127.0.0.1]:33454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGIx5-000062-9O for submit@debbugs.gnu.org; Mon, 03 Jul 2023 08:46:47 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:55933) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGIx3-00005p-4Q for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 08:46:45 -0400 From: Spencer Baugh To: Po Lu Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87cz193eno.fsf@yahoo.com> (Po Lu's message of "Mon, 03 Jul 2023 10:35:55 +0800") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> Date: Mon, 03 Jul 2023 08:46:39 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > sbaugh@catern.com writes: > >> 1. emacs -Q under X, preferably X forwarded over ssh to make things slower. >> 2. (setq save-interprogram-paste-before-kill 2000) (or any other integer) >> 3. Copy some very large data in another X client, so the selection is >> very large. >> 4. (kill-new "foo") >> 5. Observe Emacs hanging as it receives the entire large data from the >> selection owner, and then after receiving it all, discards it because >> it's more than 2000 bytes. >> >> Solution: receive_incremental_selection in xselect.c should support a >> cap on the size of the selection it receives and truncate (or discard, >> returning nil?) the selection if it's larger than that. And setting >> save-interprogram-paste-before-kill to a numeric value should activate >> this cap. > > This is not a bug because you can quit while Emacs is waiting for > selection data to arrive from the owner. When you do that, you interrupt the operation which is trying to add a new kill. If you interrupt it and try again, you'll just get the same long delay again. There's no way to mitigate this from within Emacs, other than by turning off save-interprogram-paste-before-kill. > The ICCCM provides no means for the requestor to terminate an > incremental selection transfer before it completes, and owners may > become confused if Emacs abruptly stops responding to their property > changes while a transfer is in progress. Is there really no way to avoid a large data transfer in ICCCM? Is there some way to learn the size of the selection in advance and then decide not to read it if it's too large? That would also fit the spec of save-interprogram-paste-before-kill. > Emacs should avoid doing so unless the user explicitly quits (pointing > to a problem with the selection owner anyway.) > > Additionally, the way we deal with potentially long-running data > transfer operations in Emacs is not to apply a limit on the size of > the data being transferred, but to make quitting possible within those > transfers. What may be slow for you can in fact be perfectly > acceptable for others who are connected to their X servers through > faster connections. Yes, that's why this is a customizable setting rather than hard-coded. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 03 20:40:44 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 00:40:44 +0000 Received: from localhost ([127.0.0.1]:34711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGU60-0002zf-9q for submit@debbugs.gnu.org; Mon, 03 Jul 2023 20:40:44 -0400 Received: from sonic315-21.consmr.mail.ne1.yahoo.com ([66.163.190.147]:35910) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGU5x-0002zP-Fv for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 20:40:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688431234; bh=llawFD2YFamqdCmfYZ763WFXATQp/CPlCjSOx9dIJQc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=s3Gsq2dZXP4izRx8eT3urig8r/KzD+mV7nrslD3Is1+T6kPuuwYkkL4mn7oV5omKt2IQP5PcwkLYQyIKN7AYHg+y5MuLspKUKrq3o8cCureVlXXIeM1FF+LeFJXSYopM3ylpBmD9VZhNmxc9bD6PCvyijV92WxKYIUuuR8sVXQV0XwwaRqDj2BbG7FTRgjHvfNhH68SZOlaTe8LEhO7lOkJBCZ1T7pTOLrbsrshU0AdAgqoZSkcAi9DMxhHu77pFu1aVd1Ts3R6sdpyRgw+foa8VCsD97hkSH8KIUCpjRxQdqS5pmi+dnzL3fDa+fkh45hmn4GsaOIsMSEvi6HFERw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688431234; bh=IZQ0QDxVnm/tHBBD75CfhBdVR4TxhnIjGW5chw6Bd3H=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=CjJ0174gu8r1Gt2efU03U8LkGX69j6ryjTCVkHIuFZYOIBfG8v0GKNbSNtnX4BjM52x9ayw0uJL9kub0bmaMqQybiY/rhEV4Fsfo+aQ9DNq6O10g9mvx+E1R3TOEtkucooRPOs3iu7OmNA84l65ytq+hGVrMZrG1A8v9xp4kkZqQcshmwFQzxJ8ZrpTH0cijDRyT9IPFpZ9oGb/A27Ad0j7S10lKrrvQtxfkEwaqsczV3GuFylJN3hwKD76hJT8/8fwtG5+uXXkh3GrvjxLN2/Z/VNHC+IgRpE/UK12N5sIdTGF395iL34Eu9ifTZYSB6JG20scdGgrjIxw0TKNmqA== X-YMail-OSG: 4_NqlUEVM1n2iKMWKcm6iZTkFO7ZbBQGpMEb1jhEGIdV5dse6d8CL82KGt_fN7G fdMxqq_ra256cO2LGoO3PIRolVb0qc2bKI6n3KZAnh7OX.Rids.iAxp7niMrD0ZR5C2B.F4LgsRX 2R7KoATF1_cGH61mp5.4kSOc3zEmdGijBTYOwLPrcFZPAGVBCQJ8uGo4leHQC8.S3Pj3NGOEPQQZ 8efxNIzI.8tfkYh2fNAYlSjueyqt_gyeJXV3yvFYkV9Lyod2ATDZFjBmMQ8D_OhHpAyRnM31vdrv sjnUPRInFuG7eUPkB0oKbYSHW3Gmm4O6VbK1l3J1Hv7_I536XNTfwiBXYo51NalYkjWZjkI2kPpI xeKHIAQw295_0hllsXGH3MVqy7f0BpVhN4WLhD1jFsmWkZwbhgI_BeywaU6HaoLw0380SFUlI4GH i6zOEPvJgIZhXg.SG2KOweYKUfVkMpRfFhK6MDdmD9wwfgpJYxxhkHz6Vv4hEALP3cLsRd1n15OL roAVGYJMaD5aCAjwHaxFzbD_F81PA9Sxxyt155m1ylP7OO.6BphJUw0iyBa8HIIrE8.9elFhuRXa CZMLhPzVgBajfEwMb8s0hA2uy7xmM4eigR53kMBB8leD3rKibGh8CXduTbobwum9hgW5Dgjvc70R P43wtGTBmm9MLlHwxz6XHpU3FxFVNzOecBo8Q.gKSVkI8PBOh5B9EKcdk6exnh2JGHLIEGF5cTAV ofuu.5omE.CODn8i3jGmhzsHbRrVib2IOAZpj9AGz0CPBnIbR.LvqCegGz8cZEGOp3ms3mJfLVqO zFJZbIoHqTjqHo2dpMHwjhKzO2t7vgcRhyBaGYdUrMbMN.mYiY8vJOLVPG6u8lL9H2uMmyBeC6Vf 5L05rrHX9osGXt2FoPVcS79Z2ZWhMl_Q6_hYPLYgRYjU8EV9aJUDgx4P9_bj_pCtxWpI..zIgOrd ZfoVvtu2WJ3aa20iIjOscbWw8xFshBPyhv2KqBngOEs18Jhf1YTtzrB78VOZWtZ5UAIQ24TRwdQe wBRuYAJePEW.N4WtfFYjTTNNHsJmZoeszwHvmA9BauGVkk4pXJSkbFb_BWmA8Nh6X29Yo8VMRIxp m2idJ9SimdJoKLJxE308PtguU_yudLQYUCJ7vhFjlXmpZTBGwjoFnkA0IgEXr7y3HBU4Y3y3KKUW 2i2yQ2Js_B7qHL7GMkovu9UmBYC262cva0z3s5BFq7LUVmBy9JcO8WJDH1Ck6_4cJEobqmzTonZT aOoIpQXAzvEKLywWhNaUEUsEPqAnS5BIlJe1lVhz3ojpprQvWFUUC1hEjYeKZZ1.ARyiZ5RGmsVl 4QQ2bY.0SEjMyf583jsxiwj8YacQ8nmmvSL1adR7AyRVxvCphn_rKQnxUltgviJotn0T86kt987B LXz2M9L4h5BtCuqaCJYtS7gUFrXPelV8TMTPd.Yif.YJL5lUNoel6hMfHh0jc41aZX11jQhA_88N jKbzWnHkrh.bn2JDSwu8uA1Hb8.a2fWUF4kxkxrli80egY_Jm8UtjEBrqwc1aOt4kkrvMgY7Zfr8 08lanYUrh2aEoS4EVas6bTOqwJPchKQ3q4ECrEZeFmwV_6lkPoB6Q_DtJHMMVCyvc0pq1lLbovPv FPfwnNSs_jJla4DI99itM9xXsweWNm6UswcS27yLFRNuIwj5lyL1Wkb5kXUac2Ezy1mS8uBCjuJq rRJLN5okpc2AtLzBP1B1gKkcVWAR4HQ_Kp6rvg07Dh_Y5MdVb.tddSVaq06mN.NmqB4RFD2VlBls aGzR7m1K1.UCvt_z3LfUbE_VxluH6h1NSviF9mJ3TlFyFflfkMP_mdT_h7hEgdcNzcwmcqGs817z vuZsRg4GW9w0YAk_S4frwPMWAxgp7AKkQFQlaJSKKZoIuCBSZB6nExbP48oOV4j9Br8qD6D8EXiX ctuRh_dQHnXlOWAWD15N9tTWon.ECFXasXn1xH7e_DoHKticxCx0G3nQhJFTyGUrs28j1XqYh4.L dGW5ggbZxYCsta2k9lLFawh_Y.FWkTT1b9l_LlLHPlDU93UNYlw_Jdbfb8w96xzNCue.bX.173LF fEnaxKhp436LwoRxlQBX41tBU_SCMaa.gZRSrGs3vGzANhWCTJGp6n6kmHue5ASNqaZDXtJRaqlB GTbpwpcB5qnYHoP7tLNFdIdJwSrOxBRNCvk2Lbxtt0UD7cmDB6qUe86eM5_KzQxYYjuv445ekhD. fm7Oa1Wkn_R5yaHqZn8p8PRh1ZvCArVW.BBIKkYYUI_.Yr3Z1J9CbEMbxBJpkhA-- X-Sonic-MF: X-Sonic-ID: a24c6d93-2098-471c-ab61-ee4e3bc47bbb Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Jul 2023 00:40:34 +0000 Received: by hermes--production-sg3-67fd64777-ftxnx (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID b2f31679b5170b969fd0037d244c0e44; Tue, 04 Jul 2023 00:40:32 +0000 (UTC) From: Po Lu To: Spencer Baugh Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: (Spencer Baugh's message of "Mon, 03 Jul 2023 08:46:39 -0400") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> Date: Tue, 04 Jul 2023 08:40:27 +0800 Message-ID: <87jzvgse4k.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2108 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > When you do that, you interrupt the operation which is trying to add a > new kill. If you interrupt it and try again, you'll just get the same > long delay again. There's no way to mitigate this from within Emacs, > other than by turning off save-interprogram-paste-before-kill. Then I guess the solution is to temporarily disable `save-interprogram-paste-before-kill' if a quit arrives while it is reading selection data. > Is there really no way to avoid a large data transfer in ICCCM? There is none. > Is there some way to learn the size of the selection in advance Also no. The selection owner may elect to provide a lower bound on the size of the selection data when initializing INCR transfer, but the requestor must be prepared for the owner to send transfer more data than that. > and then decide not to read it if it's too large? That would also fit > the spec of save-interprogram-paste-before-kill. Once you start a selection transfer, it must complete >> Additionally, the way we deal with potentially long-running data >> transfer operations in Emacs is not to apply a limit on the size of >> the data being transferred, but to make quitting possible within those >> transfers. What may be slow for you can in fact be perfectly >> acceptable for others who are connected to their X servers through >> faster connections. > > Yes, that's why this is a customizable setting rather than hard-coded. That still contradicts my previous remark: Emacs should not place limits on the _amount_ of data transferred in the first place (except perhaps to avoid running out of VM) but allow the user to quit from long-running operations instead. Consider the case where selection data is being transferred from an owner connected to the X server over a connection with very high latency. Waiting for a single quantum of selection data to become available (usually 64k) may still take several seconds, during which no data has been read. Because of that, limiting the amount of selection data transferred will have no effect on this delay. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 03 21:45:59 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 01:45:59 +0000 Received: from localhost ([127.0.0.1]:34738 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGV78-0004dq-SG for submit@debbugs.gnu.org; Mon, 03 Jul 2023 21:45:59 -0400 Received: from s.wrqvtzvf.outbound-mail.sendgrid.net ([149.72.126.143]:45394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGV73-0004dW-0V for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 21:45:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=yvaYKSlayjj3kqGPa3sXl691d/SA4M65cHZRxBdoHE0=; b=KZAPHf7C/1s7EPOULGgua8ZGMEyoRWMiD5+WBCvZysSU7zcus5PrbDo3PzaZ4m8eoHMu cn0ErpSAtFVoC99RlaUxPbrb+w3rb/aBZl7NUU2Hs6iAMvl20xnLSiqm5lgUM1WFl8qib1 JsYQ+p0iNUiTudkEdgyA2wTPHeop4Dzyz1N2m/Kd+rgLhjMlM22HkIsBExYW4sBpHVOVfv YsBMYUHIp1rtcaCqBuZtTUGk0Rx8lH+ggo+WCShxpA9TmMEZyuKtXOsQ0F+oakRhcz8r9e ta7gc2yAGk0qu7zUgd3f2FfxIGXrFFsVxNbECy9RV/A1u98rfUaQwAWOyhkQUoYQ== Received: by filterdrecv-84b96456cb-zd4xh with SMTP id filterdrecv-84b96456cb-zd4xh-1-64A379CA-12 2023-07-04 01:45:46.523542068 +0000 UTC m=+4673253.148329174 Received: from earth.catern.com (unknown) by geopod-ismtpd-28 (SG) with ESMTP id x3t0WA1bTDCj7DbffsQ9ig Tue, 04 Jul 2023 01:45:46.347 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=yahoo.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id C7E736001E; Mon, 3 Jul 2023 21:45:45 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87jzvgse4k.fsf@yahoo.com> (Po Lu's message of "Tue, 04 Jul 2023 08:40:27 +0800") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> Date: Tue, 04 Jul 2023 01:45:46 +0000 (UTC) Message-ID: <87pm58phyu.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbJ5RixDol=2FoIg2WQiR+Op?= =?us-ascii?Q?JEuX3hIEIAAUeNzTT40aqOZX2fo2RZ5L2CkzPOc?= =?us-ascii?Q?F0tmhs6XMy3da1nl9Yd1o5gggw0=2FiB3MYhgtkhr?= =?us-ascii?Q?BWB6DgSp+i+VlpzNNTLhENOLMNfW2Kjj4bz2UKf?= =?us-ascii?Q?+fMaZLX=2Fj2XbapBmcz6CMNPYKZQFlwUkFHw=3D=3D?= To: Po Lu X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Spencer Baugh writes: > >> When you do that, you interrupt the operation which is trying to add a >> new kill. If you interrupt it and try again, you'll just get the same >> long delay again. There's no way to mitigate this from within Emacs, >> other than by turning off save-interprogram-paste-before-kill. > > Then I guess the solution is to temporarily disable > `save-interprogram-paste-before-kill' if a quit arrives while it is > reading selection data. That would be a decent solution. Although I'm not sure how we'd implement it. We want to, somehow, know that after a selection-transfer has been aborted, we should not try to transfer that selection again. Is that something we can check? Whether the selection has changed, without transferring it? >> Is there really no way to avoid a large data transfer in ICCCM? > > There is none. > >> Is there some way to learn the size of the selection in advance > > Also no. The selection owner may elect to provide a lower bound on the > size of the selection data when initializing INCR transfer, but the > requestor must be prepared for the owner to send transfer more data than > that. > >> and then decide not to read it if it's too large? That would also fit >> the spec of save-interprogram-paste-before-kill. > > Once you start a selection transfer, it must complete That is unfortunate. That seems like a terrible omission... An important network protocol principle is "tell the client up front how much data you are going to send"... Anyway, there's still a possible solution: we could return control to the user if the transfer is too large, and continue with the INCR transfer in the background, just to satisfy this ICCCM requirement, discarding the data as we receive it. This would be straightforward in a program with a normal event loop, but might be difficult in Emacs... >>> Additionally, the way we deal with potentially long-running data >>> transfer operations in Emacs is not to apply a limit on the size of >>> the data being transferred, but to make quitting possible within those >>> transfers. What may be slow for you can in fact be perfectly >>> acceptable for others who are connected to their X servers through >>> faster connections. >> >> Yes, that's why this is a customizable setting rather than hard-coded. > > That still contradicts my previous remark: Emacs should not place limits > on the _amount_ of data transferred in the first place (except perhaps > to avoid running out of VM) but allow the user to quit from long-running > operations instead. > > Consider the case where selection data is being transferred from an > owner connected to the X server over a connection with very high > latency. Waiting for a single quantum of selection data to become > available (usually 64k) may still take several seconds, during which no > data has been read. Because of that, limiting the amount of selection > data transferred will have no effect on this delay. If the round-trip latency is 500ms, then waiting for the first quantum of selection data will take at least 500ms, yes. Subsequent quanta will also take at least 500ms each. If the selection is large, there may be many. If there are 20, then kill-new will take 10 seconds. But if we can limit the amount of selection data transferred, kill-new will only take 500ms. Wait... am I missing something? You're saying it's okay for the user to interactively choose to interrupt an INCR transfer, even though that will leave things in a bad state? Couldn't we just do the same thing in code, then? Can we wrap a user-customizable with-timeout around gui-get-selection? I actually agree now: limiting the amount of data transferred makes no sense for user experience. But limiting the *time spent* transferring data makes total sense! Users are able to do that today: We should allow users to automate that! So I think some new save-interprogram-paste-before-kill-timeout variable would work perfectly. All it would do is something users are already capable of doing, but without aborting the entire kill-new operation. That seems perfect! From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 03 23:58:34 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 03:58:34 +0000 Received: from localhost ([127.0.0.1]:34817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGXBS-0008JF-6w for submit@debbugs.gnu.org; Mon, 03 Jul 2023 23:58:34 -0400 Received: from sonic303-20.consmr.mail.ne1.yahoo.com ([66.163.188.146]:43583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGXBM-0008Iw-8k for 64423@debbugs.gnu.org; Mon, 03 Jul 2023 23:58:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688443101; bh=tJttuuOweKhw6HPBWbXoNORY7tz3eCQcZDDR6PGIhrM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=k5+o1NFLNDI66Upq40bvP4h2m3cNHRsYs1V1NSQ3uDd+yNStvaNwjhSvX5UdH/V7A4iGqF2vE7H86YANobGw2zzb9Izaknd12TYNF1eamZMEodxGVTGvdjKxUIY830EadLa97a7y20ZhyyO90/LnwtjYYMEjv9MvvqWTsROcC7Ks77GsdN2rUZcLSGgNs6PK1f0aWtcT512yUOj7UVfRztGZoqbj6caoHazSxS/SmOos75ne+RF0YhpDMKTwGJJxUjZyoOyIt2Pd1pbHdw5GPAmw3hv+roM/6IHOQhVezHe+0zuhpqqwnY0q8hL/5Bnr/tvAq/Vu32aL7v8uxBYP/w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688443101; bh=AC1yecRXm5XVyWaIdmGkapKuSLk5yuX0x4JweiSUYa8=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=sV1Z530bRolLAOYOCULk0380jCOi+H/E5bE2q1hsRoxQvFABYad5D85Evd1Rpig5cEt+gHITWQ6Af72r+UiV9omu745M7X4W8DLJm6yzwdqHb4LjC0HDnXCPv2xfbKUsYHABh3De30yCxVqYc7hAEaqCmEGH9zZ13buYYg/kh0NCY1wUUgcLN9SnmXM6LzQ05aNt2HNFWMCvOxM8aPWZYuqC2ilVvEK/OkljdL+Yzi7KlqwQ7K6hGa+Ou0xZMA2fumN7Dt7X4G9OeRNgpGCsN1ZmWeQ6wHtvMyzZcW0WWdXBg7b1wcouR/8DXVhCmtigTfBAmDhWb7vn95hFwff+Zg== X-YMail-OSG: aqNLQ0AVM1k1SQpfFHbNvvep6gYfPDel99BTliOfETfEg02YaU5oO4_6qOCBiCT N_liubUKPV6cPs.A9FzfBlNy4eioBQFXRgR48CF8jHM_z2N4uPReaHTF2ZE0lC0vPAJAgLmVhCMz tVWf2fJiLjLt7CTbqiWZw_97AM.Dd9dx15LEccJg675C5tW0lAxXLwfBV5riDNV8giZ4mBC.2yNc GMBLvrZ7zLqLPfvJw6kJ9b9_5SPZ_Za8U4SIyl4FADl3Wb4cOqzr7BizObBL86SBZEPuXZLGvzIq SoW7Rzq_bj77zkgMKmpOBNZ_xFXjNl1yDdZdVKu77yzRbHoa2KtWaAzYOcZmxDLagTDzu5J2Cq62 _05B43i5ADFFh_HIXxNEdtCxXNbidgGt8qlpopRANm9vqI3wXZUJ_1zsjTvjdL1xpU4nQOoANqTW VbWXM9jdP413IbwUeuhPz.fqdk2J2uTi7.3EMzxZ3VvkFYvUiPooyl8scbXuKcGOy9fIV1S9qqeZ 5j6z3fx9Qt1nS8W4m1e3g17uLeMP2.3yaEl3S0I7ZnPojGx62q8C4g3Px2uZmnXSGIFkDBeyBzRQ sFvQ9WvO_g5VHHon3NMshSN0EULndiVUB9dj2hO2ThJXFz.OBenmtum.7xE6OELagU6gnLrZOE.w f29pvBY3u2g08MevUDNlO6yCNZ0m3LzDgNv1ppOBr1fV94DRDLjRIUtPeaUlS8jP8zdegXlFBnUE w_ifjzzLsTagYZQJDjw7p2KsuCqxRLCY0ezKve1LaSpxXQB3HAIo__m2V0oxnQ35nZGKToTudGNO kXHuKUm_FmQ7SMhtcqa81xnm5D0Blg6PNFDK5gaZYZJTmzYoYNhxiwyvdtvOzQb4wHbTVfXwSu6z .zaPA164S8mP9Q3zSsdxSZWb2oYPWXhD0H1INE6zgSdq.ic_.irPZnq4Fhf_gmn3t9yoTNwrOKvA r5CwDM.4ZxYy5QIOsyXky.mdu7ZbhUrFUIHg7pnvkJgfI0JtRnnMJwZkNRfBKiRBAmgA4SanIR2N ylm_NDpmNFvvpXkz7KZNcsNF.2rtkDYX.hfuWRRj43EHC187Ia40qmtloOy8KMNY5dBBs8Uo94Th lKplCJy_TwShaIEFYW_DhHRfm2uuDpE6EX.ou9sXj59lu7NuUyouBUn5IV8mBzArad31hFV2NQnT MKxSTWzvuidDvljkGvPGvSIs0WE4WfYIrkM1BzB7_yRRx7k9QJ1ESS8N3fulvdPIw_7OpU36bu6m rai6W8TWzNzHu9FiVqMR_yTAGQw8fo8hXopiXnML.EMd9qQZ7R3K29DcRnHWDO6qxIBmASSsv0Xi pboxOmmP.UiOL0FYV7pDozrvlwoK3GlWr0azDwQhrlv0N6Dl_95PzZpJGXUN9V82tpDd1ElgNQpy SsdBqJxf5RdrQ7nvbneiuK95JlqFVjgMd5do8z7xKT4DeJYYEoTcjRXlWaaoCBbCCnrMDypyRWKn uftKeSDR0zWv_ZlVx6B8o46RCBXxznmfBWBnJ8XZwnoQjowXZG9VnigUr0l2KYIXZiDEY0I6evPN PR2fBS1J29Y55dfQf1IJqZHk6eNRc2p_4AYvF158qX2IrC_9ujz._TwfM4mjBMLf.iAvxXqLODBU s7uCQRHoXlDhHt4IIVsKmvYpzs0XSjPiPPCfCAD048f6lPhbfkq4_VeEmvPZGCBQNFZQy5wxPQIW Ds3rHzNPG7I8clAe.Sptd.FVnmSvk9daCM6OfD0mIFVfWjru4X1b30gPJzrF1YqRt85KMQ9JbAl8 D180aW2_SCo_BYXzauYl2qfaMrAbEonUP70ZIe3JxTSzPCiz9qQlhDju7Q8MFN3XsibFBvAWsW37 QjyCvf7qsMkKt0G5d__xWofTYRHZTpGy6StS2SmEsox1TGQPs_IXIIA_6KUIe0XUFV2C6kyDOyq0 d09KFRi6GR_YOO5dxEtgzBHYRE5x1S2sTZr8QJAfMd62zKh00sYl_Yj2b7ddjfkO0aODUuG5mBKi NAPW7rCb0EMsSMMxALaHN_lBbEWYPPqSb48abMyezd7uXTtp6ZbMXeaEk7kixyWqXKMl0C1x4PRP mpA70ddlG_8IYtHEwxuwB0fCKO2Mi8XKxWFb9A1.qrMXFP_QvdE.FrIgFjvXBE92Xyjz8xZw6M1c WJ4RYFNDKaEeFqp_nUfooTkN1NqjSZyZpdoMRaQQh8gFR9ESnJ6WQdlbi7r8tvhTd769K1DEnE3r dKy5EATpT_kGUZm53lOQGzi3e28_l_.bS_pEdOHWd6zCAc5xKLve3.Yu2u4yxaYA- X-Sonic-MF: X-Sonic-ID: 6967b7bd-8d1d-414a-9cf8-0b2fc46b4994 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Jul 2023 03:58:21 +0000 Received: by hermes--production-sg3-67fd64777-bps25 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 710eba99a3ff08195bed742fd49e84bb; Tue, 04 Jul 2023 03:58:15 +0000 (UTC) From: Po Lu To: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87pm58phyu.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Jul 2023 01:45:46 +0000 (UTC)") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> Date: Tue, 04 Jul 2023 11:58:10 +0800 Message-ID: <87y1jwqqel.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 3632 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) sbaugh@catern.com writes: > Po Lu writes: > >> Spencer Baugh writes: >> >>> When you do that, you interrupt the operation which is trying to add a >>> new kill. If you interrupt it and try again, you'll just get the same >>> long delay again. There's no way to mitigate this from within Emacs, >>> other than by turning off save-interprogram-paste-before-kill. >> >> Then I guess the solution is to temporarily disable >> `save-interprogram-paste-before-kill' if a quit arrives while it is >> reading selection data. > > That would be a decent solution. Although I'm not sure how we'd > implement it. We want to, somehow, know that after a selection-transfer > has been aborted, we should not try to transfer that selection again. > Is that something we can check? Whether the selection has changed, > without transferring it? Emacs will probably assert ownership of the selection after the kill takes place, anyway, so there is no need. > That is unfortunate. That seems like a terrible omission... An > important network protocol principle is "tell the client up front how > much data you are going to send"... It's an intentional omission: INCR data transfer is designed to work even if the owner itself does not know much data will be sent. For example, if the selection data is being transferred from a pipe or socket. > Anyway, there's still a possible solution: we could return control to > the user if the transfer is too large, and continue with the INCR > transfer in the background, just to satisfy this ICCCM requirement, > discarding the data as we receive it. This would be straightforward in > a program with a normal event loop, but might be difficult in Emacs... It's straightforward in Emacs, since that's already how it responds to selection requests from other clients. But it's a bad idea: what if the user requests another conversion from the same selection owner while the transfer is in progress? This is technically possible, but will need Emacs to specify a different property in each ConvertSelection request, which will lead to lots of needless InternAtom requests and round trips... > If the round-trip latency is 500ms, then waiting for the first quantum > of selection data will take at least 500ms, yes. Subsequent quanta will > also take at least 500ms each. If the selection is large, there may be > many. If there are 20, then kill-new will take 10 seconds. But if we > can limit the amount of selection data transferred, kill-new will only > take 500ms. > > Wait... am I missing something? You're saying it's okay for the user to > interactively choose to interrupt an INCR transfer, even though that > will leave things in a bad state? Yes, because when the user choses to do so, it is already clear that there is a problem with the selection owner. Transferring a lot of data is not a capital offense, and Emacs shouldn't condemn the selection owner just because it does. > Couldn't we just do the same thing in code, then? Can we wrap a > user-customizable with-timeout around gui-get-selection? > > I actually agree now: limiting the amount of data transferred makes no > sense for user experience. But limiting the *time spent* transferring > data makes total sense! Users are able to do that today: We should > allow users to automate that! > > So I think some new save-interprogram-paste-before-kill-timeout variable > would work perfectly. All it would do is something users are already > capable of doing, but without aborting the entire kill-new operation. > That seems perfect! You mean, x-selection-timeout? From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 07:46:44 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 11:46:44 +0000 Received: from localhost ([127.0.0.1]:35111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGeUW-00011s-Bq for submit@debbugs.gnu.org; Tue, 04 Jul 2023 07:46:44 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:31492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGeUS-00011Z-SQ for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 07:46:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=Y8Q+XLlcM9UD7sRJ40n/h6XFb6hnMG45/os2J3WU+40=; b=yRP3qEp4106qj4Sw0amAXD+lixa8sybplNcNjzQbvokf3d4aDwvE5TpepV+TxWOqyM4U zPFta61HpK4FFrIQVGBD7o+I/rqQ37B4WxU2QxkHP4oSHrxoFlgHRyhPT7KaLBsk3Wz2Wq 6ht9EkOAFnozjcYXyFVXCL49TRxMvFsgwfGrTm6D28TE1Nlp8P8Pi+N2A7aXsPH0EbJM42 km6IZ9NVQb3Hu++9eHi6I76l7ZqpOGH2CZvmzBoPA8Xa613vWsUZcOpCRGUMdmDSsuWUkS q6anbVDaNk1lQUpi5AezIawrfNZihCdM9cPAoQdAKPidVvnj6eDh+/1OQbGmn3Hw== Received: by filterdrecv-d7bbbc8bf-nxr9l with SMTP id filterdrecv-d7bbbc8bf-nxr9l-1-64A4069A-13 2023-07-04 11:46:34.327030306 +0000 UTC m=+4709216.412763670 Received: from earth.catern.com (unknown) by geopod-ismtpd-4 (SG) with ESMTP id xpOCG29AQy-E71kAazlngA Tue, 04 Jul 2023 11:46:34.202 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=yahoo.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id BB92660159; Tue, 4 Jul 2023 07:46:33 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87y1jwqqel.fsf@yahoo.com> (Po Lu's message of "Tue, 04 Jul 2023 11:58:10 +0800") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> Date: Tue, 04 Jul 2023 11:46:34 +0000 (UTC) Message-ID: <87mt0bq4py.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbIhZLy9DqN3P+8z5Q465A?= =?us-ascii?Q?OKRAq9Cp89dNvmZ85DaxubXuCj7kvA7BiyIIEyz?= =?us-ascii?Q?aH1x+29nvTKhcZwVQV3n2Cf5nsdMpwCtJLqbwT2?= =?us-ascii?Q?MBKV4jw4nOcKJKDMdgjE2sYqmWolsTHTuyrYqur?= =?us-ascii?Q?JVmX1FDzlY9I=2FvvAxDSmOWD19qiVhjjxPlQ=3D=3D?= To: Po Lu X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > sbaugh@catern.com writes: > >> Po Lu writes: >> >>> Spencer Baugh writes: >>> >>>> When you do that, you interrupt the operation which is trying to add a >>>> new kill. If you interrupt it and try again, you'll just get the same >>>> long delay again. There's no way to mitigate this from within Emacs, >>>> other than by turning off save-interprogram-paste-before-kill. >>> >>> Then I guess the solution is to temporarily disable >>> `save-interprogram-paste-before-kill' if a quit arrives while it is >>> reading selection data. >> >> That would be a decent solution. Although I'm not sure how we'd >> implement it. We want to, somehow, know that after a selection-transfer >> has been aborted, we should not try to transfer that selection again. >> Is that something we can check? Whether the selection has changed, >> without transferring it? > > Emacs will probably assert ownership of the selection after the kill > takes place, anyway, so there is no need. Good point! So maybe if a quit arrives while we're reading the selection in kill-new, we should immediately take ownership of the selection. With an condition-case, perhaps. Or... just ignore the quit. If we're reading the selection in kill-new and there's a quit, just proceed to doing the kill. >> That is unfortunate. That seems like a terrible omission... An >> important network protocol principle is "tell the client up front how >> much data you are going to send"... > > It's an intentional omission: INCR data transfer is designed to work > even if the owner itself does not know much data will be sent. For > example, if the selection data is being transferred from a pipe or > socket. Ah, I see. Then, like pipes and sockets, it should really at least support interrupting the transfer... >> Anyway, there's still a possible solution: we could return control to >> the user if the transfer is too large, and continue with the INCR >> transfer in the background, just to satisfy this ICCCM requirement, >> discarding the data as we receive it. This would be straightforward in >> a program with a normal event loop, but might be difficult in Emacs... > > It's straightforward in Emacs, since that's already how it responds to > selection requests from other clients. But it's a bad idea: what if the > user requests another conversion from the same selection owner while the > transfer is in progress? This is technically possible, but will need > Emacs to specify a different property in each ConvertSelection request, > which will lead to lots of needless InternAtom requests and round > trips... Such costs only need to be paid if there are indeed multiple conversions happening at the same time. In the common case there's just one, so there's no extra cost of adding the ability to have multiple ongoing conversions. Actually, how does this work today? If an Emacs user quits a conversion and then immediately starts a new one, that seems to work fine. We don't do different properties in each request. I realize the protocol doesn't support it, but doesn't that suggest that it's fine in practice to interrupt a conversion...? (Quitting a conversion then running another would be one way to have multiple conversions at the same time. Another way would be (related to my other thread about call-process) to allow running Lisp while an incremental selection transfer is ongoing. I know that seems useless but I really am of the opinion that every blocking operation in Emacs which can take more than a few milliseconds should support running Lisp while it blocks...) >> If the round-trip latency is 500ms, then waiting for the first quantum >> of selection data will take at least 500ms, yes. Subsequent quanta will >> also take at least 500ms each. If the selection is large, there may be >> many. If there are 20, then kill-new will take 10 seconds. But if we >> can limit the amount of selection data transferred, kill-new will only >> take 500ms. >> >> Wait... am I missing something? You're saying it's okay for the user to >> interactively choose to interrupt an INCR transfer, even though that >> will leave things in a bad state? > > Yes, because when the user choses to do so, it is already clear that > there is a problem with the selection owner. Transferring a lot of data > is not a capital offense, and Emacs shouldn't condemn the selection > owner just because it does. > >> Couldn't we just do the same thing in code, then? Can we wrap a >> user-customizable with-timeout around gui-get-selection? >> >> I actually agree now: limiting the amount of data transferred makes no >> sense for user experience. But limiting the *time spent* transferring >> data makes total sense! Users are able to do that today: We should >> allow users to automate that! >> >> So I think some new save-interprogram-paste-before-kill-timeout variable >> would work perfectly. All it would do is something users are already >> capable of doing, but without aborting the entire kill-new operation. >> That seems perfect! > > You mean, x-selection-timeout? Yes. Personally I'd like to have a lower value for that when a save-interprogram-paste-before-kill is triggered. So adding a separate save-interprogram-paste-before-kill-timeout which can be lower, and which let-binds x-selection-timeout, seems good. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 09:20:17 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 13:20:17 +0000 Received: from localhost ([127.0.0.1]:35169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGfx3-0003W8-6y for submit@debbugs.gnu.org; Tue, 04 Jul 2023 09:20:17 -0400 Received: from sonic301-31.consmr.mail.ne1.yahoo.com ([66.163.184.200]:33422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGfx0-0003Vo-By for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 09:20:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688476807; bh=Zk9TIpP9pSvYR5zQT+REqmq0xEjVBeFcsgr8bXXGV2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=txkboh9vQtTISk1/vuDApX4MiSGBKZY99qWoXbUq97+6duZza3FRNTfh8mXLb2rIkOUTyssVND17q/hFYlGLkyY4Igvxqm7fq/+3MTwPuh6ltjoCIhq0u39TiXEeAujmY/nJprEs2XDDiCflUIF5+vK+yRrXfuZO9HcT7LTYZoqprSok4fBSkMFdJRFbb7LutWFqkptqlyRKd30mCmlKDVw9NTSWY7ytD1IRPWBSArayohAPGRhI1jOPlH5ldoP03oPxo2Mkb5CkmOgf6TqPPvnRYMeMmXGZtNDPhwx6eyr+FKzGmKVh1UpRba0zzK5GSnk6mKYM5hx4jud2/RO3DQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688476807; bh=DUaZX0v70QhGRZaHR/GaBz0grUtVIb54QYDiZzbiur9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=rgc5bNLngmGxrRD4JWp0TVb05bRnlyioGg2LYmQ56ai/N+ihCzmiOcMu1wD8DnMoj3O/B3y5Ch5e/0EKXhrFuEDfg8nBRtmeoFUy+KxdOIt5yif/JYHwL8FydU2GhUdcYFl7Z31bvf3n+BN20j6vZ6uSDMl4L5OGc8Tck70J3qeswLo2Qk5a+n35PStU3CMAwvAKv3icMZiQ7vbALEPqK/yfDYkRVfcnyWvpm84WYjedczKtISPBgcfgcHIkACF7TgR5XizYf0xnZOKeuIvyMKY1EhUMTpNYLXG5eeSbS6EYSrXj1XcFbEcj+zczoiZzCIBURsDbujnb0ZMQIoxYIw== X-YMail-OSG: EpLjIyIVM1k66PHetsZmafRxrE0hUEI.4GZ2XbOpeg3ndL44mim94dzB3tJWBec FwNPwoWLVqTMDIkJn3QO7DwA5baa.3LpY1WT7Ob6j9gDSIPHxuKft5Tb987ZdQ7rYcn2sDk9.w4e mP7gg.A0F0G4NKXBU7eFg.HO6OCfTbPuZ53xz.VF3ahXyvt2EkQqFdaUu0_8IgRDLY_VXqOMH8Mh nQz0Ivc_RaSLcmfuLPkgQZL9cYAD9adCjEM8WRXOvgxHVEwN9o80SAMcH5PKN9QcmEWkF2ouM6KE eQy9wTR3_18B_JGxYpMFNAdHC77XoEac7GRhLgMo2OkKFxEeftWR6gNzZX_YNpA3QsVwI2eY9jv8 KnOQ5QqGnSHo1GgflKaZw3wve5t1KEY3eqAZW3xGYTDBJ3gNgNqT5qcFQOkSF4JSNcIce8uUUJPD DbBPwiFBEf6KZdiikpQGYUf3.2Gy1km5u8uMoV4Gz6_L.geFSFOIWMvIPgJb.ki1Icm1d627QT4u wNvPwrT9nodh3co076ipYmAx9B_7az1RkCmn9I4LZAPqcl1cTA_25e42TZxl0Ki1ixWVo3S11nyk 3JN_l8X5XG5Y.XTx44221aaJ5Vjup_AxzDaVTQQumEIY.o_0TwQpTRrXRzRE8jVoWjhAOhGpEnig E1LSiEM6Cm08823iS1wCsBZLk.r.4JjbotQtvxz5H6kV8gA50rfV.uoOwB.d.PYOwvCagssHnLgj GCT0Lr.2ABlcObtEH9F19JpYDLgwxqS84wcP3Gv94RmX4qzPurP4UULn0OufRQ9rotWVnpW8P2Ew cAYYtxIXXu8.EaLMxFu2N68DLlJlY3IJgTPRJVUPQkaHY7_MzxmU1wwIILwX4Sz2EugH76tB4oAW blvRSAsJJZWekgGfdi4KjRBMT7a3JARDjD99PMXMUMU6mN.VJX8Kxsw6CSvNSox026.6yCSRehw8 7cAZeIwyMqJJr3aXLU4LVLZNXfP5CYk_JYJDCXlqiytWhz06qT7QJMRk4TTNYxE9np58i7n8kY7d YT.4WULPcvKWKsyohuCVRuVr5ZFfTuG3vHDYE5RULQOk3Hi7MQdGzWOIb9QXUyAldw9UiHaBGzCK qXPcLub9KRHbuzJA.HX3wcawN.y_Cv8QirKXectIh53jkdAHLJG.nbRaERAMjg5OUtqaxXTrqb6T yB7qXfdjaZzflGme8nwDqLpUdyclwp7lTD_KEPM.3PXHf.Dgl8sNz0P.MKB6J0mbKMwi6f_E8fMv Jog.OcS90FBQsKTb5g2FMgG971JLDq.uzt5jAvXiw_.Jch.Ftr8dAzPYXx8HmeHfpfN2hoyLMpVe mkeOb_DrO8NJLDRBzG2HWJKa3DpeHwcak5GelD3zbL00yCu_sG_aSmpna3_QrTxVw0Tnd0CY0KLr jyiYjrLYYAky_QkCRrzOPfkqDFPoZT.XRGXOHkCSVECJxSbesaiWNC6kSs0zwx4_bNwp.RgY6vde ZISchBMkjERUrcusZ.DmyAVoSHORPmFB0CMZag4e4c2COSdCIqAJv65WwGdCR8cPyQIzMPbUcdQc PsOjMXuNesMvsrHeQnujvaLFB6Ryh_tOEnKeU2Hm8rgdg1RkBQcu0PlFR5GXx0D9qmn7XiyZVYyS K2KabWGy81MFET_Um23p4qrDzclDWddvp_hAh4dhqpRwXtjizagcUjQRmvp0WvM.tgch5MJ3Ed_M NwaIwT2V0jQ.VbAFTn2tPjk.l_3wW.GyThawwwe6b0J5mK8jiRrIxiffHKobhVRzHv7MNQmlFJbb fzJ_4R_qiD9pcenu0qsWsxtmF90IqUevy9T_6cMMLlOdxtqjI7G_5dtBg.a4dZc_gIIZHwgSpubh QqjLJ5R9hxiPkm2hOJNX_zR89NgitG_pDzT8J2cNCDJ7GKppHzWZtSmVIetF4Z8gzmckpADah5r_ Frjet2GfBi1XW_vDAq_y_dPRePG9fuSiubHY1qljLamzn3zBnHfMnVmWhP_z7gqueN43u24hj7.W 1DiCdjFR6VaVDLF1Wqz1CRvqACt1ZQ6eaFFush0.jxsBXGdt339jv2NfhrmcGveFL3K2SDT08CBO Vh4D0MT_Jgghv_38RzsoF4W0WZNPs45ocLTFlbaBlo2JOh3_SQKruB9Pa08bi9WM0Uf7WcfpiJF_ HAFioTxvscru6cKfncVT0Z5nYNAP40cGn_R4u1XZBjIldnk0F3UAWNKrje4IGsgrnQAJhV_iYJHo pFtEWKvcyeTpignQ6CBHEBbcABujK6lDW22MUEZ4YMZZm4QWzJcSONb5JCHfm.T0- X-Sonic-MF: X-Sonic-ID: f7351589-29e5-46d6-9209-2d9ac8542b11 Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.ne1.yahoo.com with HTTP; Tue, 4 Jul 2023 13:20:07 +0000 Received: by hermes--production-sg3-67fd64777-rc8tr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID f06502479f5f681561df9d89ec264d8f; Tue, 04 Jul 2023 13:20:02 +0000 (UTC) From: Po Lu To: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87mt0bq4py.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Jul 2023 11:46:34 +0000 (UTC)") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> Date: Tue, 04 Jul 2023 21:19:51 +0800 Message-ID: <87h6qjreyw.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2942 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) sbaugh@catern.com writes: > Ah, I see. Then, like pipes and sockets, it should really at least > support interrupting the transfer... It's 30 years too late for changes to the ICCCM. So we will have to make the best out of what we have. > Such costs only need to be paid if there are indeed multiple conversions > happening at the same time. In the common case there's just one, so > there's no extra cost of adding the ability to have multiple ongoing > conversions. Adding extra round trip cost to a part of Emacs that is already one of the slowest and most synchronous components of the X Windows support is unacceptable in my book. Especially for such an uncommon situation: I can't remember the last time I quit a selection request to a working selection owner, and I use Emacs over wide area networks every day. > Actually, how does this work today? If an Emacs user quits a conversion > and then immediately starts a new one, that seems to work fine. We > don't do different properties in each request. I realize the protocol > doesn't support it, but doesn't that suggest that it's fine in practice > to interrupt a conversion...? If Emacs quits while waiting for a property change to take place, and the property change event from the recipient of the request that was quit still arrives, Emacs will become confused and return outdated selection data. Or even worse, a mixture of the selection data from both the new and old owners. Selection owners that are not implemented robustly may also freeze if Emacs quits before removing the selection transfer property from its window to acknowledge the selection data's arrival. > (Quitting a conversion then running another would be one way to have > multiple conversions at the same time. Another way would be (related to > my other thread about call-process) to allow running Lisp while an > incremental selection transfer is ongoing. I know that seems useless > but I really am of the opinion that every blocking operation in Emacs > which can take more than a few milliseconds should support running Lisp > while it blocks...) No, it's only necessary for us to ensure that C-g works, so the user can always quit from the long-running operation. Otherwise, your position cannot be consistent without insisting that constructs such as `while' also check for and run timers and selection converters. > Yes. Personally I'd like to have a lower value for that when a > save-interprogram-paste-before-kill is triggered. So adding a separate > save-interprogram-paste-before-kill-timeout which can be lower, and > which let-binds x-selection-timeout, seems good. How is that different from setting `x-selection-timeout'? IOW, what's your real-world use case for such an additional option? Have you tried adjusting `x-selection-timeout' for all selection transfers? Let's not overengineer the system independent interprogram code with X-specific options. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 10:46:49 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 14:46:49 +0000 Received: from localhost ([127.0.0.1]:36419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGhIm-0000K7-II for submit@debbugs.gnu.org; Tue, 04 Jul 2023 10:46:49 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:26334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGhIh-0000Jl-1a for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 10:46:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=+pTNEUhtPJs2Bs//ZDT6rhq2vC+wy4qECb35mucE4mQ=; b=ITp2L1Hv90byoZ8rOJmkshf7soWWdtXJRuE685gXqqaZKlylq+I6D7XSm4f9vq2E8GjX p8CezI2dKsTggTs4L5uw3ZQA5Vbwt9YLnjH+ReFzn1ctP4wCaj1BNc4xlWalyZbXkAojrg 0z0Xm//vCKqqtWHJgnb2uQ9iohgKTWYCxXAI3FwkDYKIH9s3DtvOmw03v9gJv/ACocQudh nQyiWhlnEOzQAMWOkMNOcYi7c8jaWOQpG2adOsrw7rAY/Ve/H71PPYksA/Ee2+XjgAHiR8 q3Ac9cqwAteMTJ1txIc6fGjujCx3t2gOv+IDQBOkCkpOW1+OraOuvRHJyKMoZmvw== Received: by filterdrecv-8684c58db7-nfltn with SMTP id filterdrecv-8684c58db7-nfltn-1-64A430CC-75 2023-07-04 14:46:36.697274847 +0000 UTC m=+4720084.975447428 Received: from earth.catern.com (unknown) by geopod-ismtpd-16 (SG) with ESMTP id wf-GU24XSNqoUkjEvS-mOw Tue, 04 Jul 2023 14:46:36.364 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=yahoo.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id D16B36015C; Tue, 4 Jul 2023 10:46:35 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87h6qjreyw.fsf@yahoo.com> (Po Lu's message of "Tue, 04 Jul 2023 21:19:51 +0800") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> Date: Tue, 04 Jul 2023 14:46:36 +0000 (UTC) Message-ID: <87jzvfohtg.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbL8pxP=2FfGIayP8u9Yrrwh?= =?us-ascii?Q?cwZzKrjD=2Fzsv42A4tqPhMX23ZjJskVzj7SSmxJL?= =?us-ascii?Q?Azl5ojgs6MavhuhT2ix9huRmoNiyQ9insQilgCm?= =?us-ascii?Q?btV0xUPb+mwqBb+djDp8VAjjSqDwFBProiDO1oi?= =?us-ascii?Q?vvkG5esXkhtjb9F6xKdrslfx6zSNNIm6hkQ=3D=3D?= To: Po Lu X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: >> Such costs only need to be paid if there are indeed multiple conversions >> happening at the same time. In the common case there's just one, so >> there's no extra cost of adding the ability to have multiple ongoing >> conversions. > > Adding extra round trip cost to a part of Emacs that is already one of > the slowest and most synchronous components of the X Windows support is > unacceptable in my book. Especially for such an uncommon situation: I > can't remember the last time I quit a selection request to a working > selection owner, and I use Emacs over wide area networks every day. I think you might be misunderstanding me? Just to say again, in the normal case, this would not add extra cost. This would only add extra round trip cost in cases which, as you say below, currently just confuse and break Emacs. (Also, the entire point would be that this component would move from being synchronous to being able to run in the background, concurrent with other things.) >> Actually, how does this work today? If an Emacs user quits a conversion >> and then immediately starts a new one, that seems to work fine. We >> don't do different properties in each request. I realize the protocol >> doesn't support it, but doesn't that suggest that it's fine in practice >> to interrupt a conversion...? > > If Emacs quits while waiting for a property change to take place, and > the property change event from the recipient of the request that was > quit still arrives, Emacs will become confused and return outdated > selection data. Or even worse, a mixture of the selection data from > both the new and old owners. > > Selection owners that are not implemented robustly may also freeze if > Emacs quits before removing the selection transfer property from its > window to acknowledge the selection data's arrival. OK, interesting. So it's basically broken already today to interrupt a gui-get-selection... great. >> (Quitting a conversion then running another would be one way to have >> multiple conversions at the same time. Another way would be (related to >> my other thread about call-process) to allow running Lisp while an >> incremental selection transfer is ongoing. I know that seems useless >> but I really am of the opinion that every blocking operation in Emacs >> which can take more than a few milliseconds should support running Lisp >> while it blocks...) > > No, it's only necessary for us to ensure that C-g works, so the user can > always quit from the long-running operation. Otherwise, your position > cannot be consistent without insisting that constructs such as `while' > also check for and run timers and selection converters. This is becoming tangential, but, yes, I will bite that bullet. "while" should also check for and run timers and selection converters, when Lisp code opts-in to that behavior. I can think of several ways to implement this without hurting performance. IMO the major issue with the Emacs UI at the moment is that it blocks too much, relative to "modern" applications. Some of this blocking can only be fixed by speeding up Lisp execution, but substantial parts of this blocking can only be fixed by making Emacs more concurrent - that is, making it possible for Lisp code to run concurrently with other Lisp code, on an opt-in basis, instead of blocking all Lisp execution while operations like gui-get-selection and call-process are running. I am aware this is a major undertaking, but I think it's important for Emacs to compare favorably with "modern" applications which don't exhibit as much random UI blocking. I regard this as basically equivalent to the lexical-binding transition. >> Yes. Personally I'd like to have a lower value for that when a >> save-interprogram-paste-before-kill is triggered. So adding a separate >> save-interprogram-paste-before-kill-timeout which can be lower, and >> which let-binds x-selection-timeout, seems good. > > How is that different from setting `x-selection-timeout'? IOW, what's > your real-world use case for such an additional option? Have you tried > adjusting `x-selection-timeout' for all selection transfers? Here is the real-world use case: When I yank I'm willing to wait for 2 or 10 seconds for the paste to complete, since the paste is what I actually want. But when I kill-new I want to wait less time, because the save-interprogram-paste-before-kill behavior is just a nice-to-have, which I want to happen if it's convenient and fast, not the actual thing I want to do. > Let's not overengineer the system independent interprogram code with > X-specific options. Thanks. A gui-selection-timeout would be fine with me, too. Maybe other systems would benefit? pgtk? From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 12:18:50 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 16:18:50 +0000 Received: from localhost ([127.0.0.1]:36481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGijp-00085O-ID for submit@debbugs.gnu.org; Tue, 04 Jul 2023 12:18:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGijo-00085A-2E for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 12:18:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGijh-0005bw-LW; Tue, 04 Jul 2023 12:18:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=preWAMfcFqlWNgyIbHlwbN1I3lAfVXu7lkqkx32fafc=; b=jNx4+AZgkBEc jFX3BTG3k+1MnbW5B9+0fLhE2d6ppluAbb195rBHI67vU1iqHKu8/orYpktfMLu/3SFfIDftiDlzX nY/Vz94D9cfzmvjatt8MhD/XXEArt3+0UCd6FYZ4Sc1Oe3ntMeoMyEMFFydWSqtA6EwMSdEQ7ypKX TwppLSTbGVuuyDEVqPyG0bDfUZXm+/ix0pEu88iRBL0LQh0dLsFtif981OQTNCtnJIfRoqeCY6Jbh oIeNBeBnmkV5ox8870C7zAiqPUdzRUFrzNK0j4o/Ngo8OzZsCMkYJZSMKiXDhzZN4vDCyjl7MNIU0 W+mw2kLlajh6ulQXSpj8kg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGijh-00020y-5L; Tue, 04 Jul 2023 12:18:41 -0400 Date: Tue, 04 Jul 2023 19:18:36 +0300 Message-Id: <835y6zlkf7.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87jzvfohtg.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Spencer Baugh , 64423@debbugs.gnu.org > From: sbaugh@catern.com > Date: Tue, 04 Jul 2023 14:46:36 +0000 (UTC) > > IMO the major issue with the Emacs UI at the moment is that it blocks > too much, relative to "modern" applications. That is true, but it cannot be fixed by small half-measures. The basic Emacs design _assumes_ this single-threaded operation, and many of the low-level parts will simply break if the assumption becomes false. Some will break visibly and loudly, some will break subtly and silently, but they _will_ break. We have seen this many times: the seemingly-confusing code which does things no one completely understands turns out to do all that for good reasons, which only become visible when we in our arrogance boldly make changes no one imagined when this was designed and implemented. And people who designed and implemented it, and improved it over the years, were and are very clever, and knew what they were doing and why. The _only_ sane way of getting a non-blocking Emacs is to redesign all of Emacs around that idea. > Some of this blocking can > only be fixed by speeding up Lisp execution, but substantial parts of > this blocking can only be fixed by making Emacs more concurrent - that > is, making it possible for Lisp code to run concurrently with other Lisp > code, on an opt-in basis, instead of blocking all Lisp execution while > operations like gui-get-selection and call-process are running. You cannot "make Emacs more concurrent", not by and large. We can make small improvements here and there, if we tread cautiously and do careful damage control after each such change, but that's all. If you look at the low-level code in Emacs and take time to understand how it works, you will agree with me. (And if you don't agree, we will have this very argument again many times in the future.) We should accept that fact, and either live with it or start a new-generation Emacs, based on very different designs. Anything else is just lying to ourselves. > I am aware this is a major undertaking, but I think it's important for > Emacs to compare favorably with "modern" applications which don't > exhibit as much random UI blocking. I regard this as basically > equivalent to the lexical-binding transition. Ha! Lexical-binding transition is nothing near what you propose. It changed the language and its interpreter, but not the editor and its infrastructure and primitives. What you suggest is several orders of magnitude harder (read: impossible). From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 12:32:45 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 16:32:45 +0000 Received: from localhost ([127.0.0.1]:36516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGixI-0000FI-To for submit@debbugs.gnu.org; Tue, 04 Jul 2023 12:32:45 -0400 Received: from mout01.posteo.de ([185.67.36.65]:42117) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGixH-0000F1-6e for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 12:32:44 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2D1AA240029 for <64423@debbugs.gnu.org>; Tue, 4 Jul 2023 18:32:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688488357; bh=ErgbhtRMbybpgHYA7GUQNAA3bDlZBXRMAU49DsApY1M=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=UsSF3rpg6hzwt9WIWNWmAQcfuBulecnt1Nle3xFzXrh6yK7YjPOA6hEYIN2yX8EWF 99ojgA63id/AAUhHe4hnvBYEbnju2dR2O0HYitdt9wk66V3vn5cSK2X2ZoVo/JOljr 4LSlBmSI7O3ghnIUq6RQxMpI9ga7AFKfHpuAV6JI0xK3DgPQ+hoHlo2BsCdZpBHwQN zcAAUP7/vmftiay5raPEZptgw8SJEbQwsKMoflF69Sd07Ex9YQOfZ0wxxGXh5UsFG1 UVsY0aKsfoKLHeTavuhqch0JLJsliuckEJ6ybhbhP5jOTLBUVZzh7NNFRZUQsWxCO2 RVLtUBqkCwvtQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QwSxw2xlSz6tvd; Tue, 4 Jul 2023 18:32:36 +0200 (CEST) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <835y6zlkf7.fsf@gnu.org> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> Date: Tue, 04 Jul 2023 16:32:31 +0000 Message-ID: <877crfr61s.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@catern.com, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > You cannot "make Emacs more concurrent", not by and large. We can > make small improvements here and there, if we tread cautiously and do > careful damage control after each such change, but that's all. I feel that I am repeating an already proposed idea, but what about concurrent isolated process that interacts with the main process? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 12:41:50 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 16:41:50 +0000 Received: from localhost ([127.0.0.1]:36521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGj65-0000Tv-W5 for submit@debbugs.gnu.org; Tue, 04 Jul 2023 12:41:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGj62-0000Tc-CY for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 12:41:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGj5w-0002kt-MI; Tue, 04 Jul 2023 12:41:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=0qz/MRiwBbQ4mv2GQ1NWLFM5AFroYaT/fS1dNrdlE0Q=; b=D9smKM7XrJD3 8EW/7cOljm6PIJfvdoxHXwiLS9u/fThMlhC5+fnT9N24U1yvarZ6YGjZSWF3XHU7fXxSfmTYIwY3o /qZCgJeFoB5ISskaKT5EHEQOVy9NFw4rjUx7mDr3ELFziq1/har9k9dQZRGNmAhH89mn50mZSDSk5 UqSP3tGiVLJxe+aREuYsOn32DclE5eCruZeteaXkqRC8GZNJRLl4UUWfnhEnX0HjuoMN+S6qWEZNw wV9uUDca2Ay/w71th0o873E3mFir+TeRYcbSl403Nxpxyg3dw5aC38gd+/0Zyc4PY17ffppmdaQE2 A/waHBz0NHZHzg/oWYipRA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGj5w-00020e-6Q; Tue, 04 Jul 2023 12:41:40 -0400 Date: Tue, 04 Jul 2023 19:41:36 +0300 Message-Id: <831qhnljcv.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <877crfr61s.fsf@localhost> (message from Ihor Radchenko on Tue, 04 Jul 2023 16:32:31 +0000) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <877crfr61s.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@catern.com, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: sbaugh@catern.com, luangruo@yahoo.com, sbaugh@janestreet.com, > 64423@debbugs.gnu.org > Date: Tue, 04 Jul 2023 16:32:31 +0000 > > Eli Zaretskii writes: > > > You cannot "make Emacs more concurrent", not by and large. We can > > make small improvements here and there, if we tread cautiously and do > > careful damage control after each such change, but that's all. > > I feel that I am repeating an already proposed idea, but what about > concurrent isolated process that interacts with the main process? (This stuff should not be discussed on the bug tracker, but on emacs-devel.) If you mean what the async package does, then yes, this is a workable idea. But it doesn't need to change anything in Emacs, and it has some downsides, like the difficulties in sharing state with the other process. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 12:48:14 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 16:48:14 +0000 Received: from localhost ([127.0.0.1]:36531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjCI-0000iL-7E for submit@debbugs.gnu.org; Tue, 04 Jul 2023 12:48:14 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:50474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjCG-0000hQ-6c for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 12:48:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=aCpyf+/8/ip3XpmkPEBnKDfvnZSFs3V8jgMlG8aKDzs=; b=INpLm+uE8NVzkkjeI9LIYSXMFORqFEMAwmow4Vm9XKHt3/j+emnXuNXr4xi+s8DQ1hp1 J+pqAFrnNmbzZf0HW0AE1+M9dCmqq/16NcZJy6+9GIlxHuQczkIxZiSRkeon7/8yXJBf/3 QOZMEPqfdU4LiV47KjouQdxRUJCf59cF5Fubay1dJ4u2bAX+jLaIkzIiNs+s6UHrCdJofZ +YeJxUmcG0eIde4p+G9hJnFIpIDl1Cs2htro/yxjV+SP4MQch/3FdskLyF+nEkK52IEBpD hT5VEk3gWHKnBQyTx3JCO1+tCtEGkzizbCJoQUiJv0tJ+ByUoo9JmVdzcJLcsujA== Received: by filterdrecv-d7bbbc8bf-jcg2g with SMTP id filterdrecv-d7bbbc8bf-jcg2g-1-64A44D46-B 2023-07-04 16:48:06.080754702 +0000 UTC m=+4727307.931957906 Received: from earth.catern.com (unknown) by geopod-ismtpd-5 (SG) with ESMTP id yUH3CEkjSEKmh1k-xj68Xw Tue, 04 Jul 2023 16:48:05.939 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 8E3EC6009A; Tue, 4 Jul 2023 12:48:05 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <835y6zlkf7.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Jul 2023 19:18:36 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> Date: Tue, 04 Jul 2023 16:48:06 +0000 (UTC) Message-ID: <87h6qjoc6y.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbIfc5qXNE3Om=2Fd+wnoBbC?= =?us-ascii?Q?sMiJaRuY38EScS79gK0mkhiMOx+kwqq1qMvwPAq?= =?us-ascii?Q?718LqS6+WY4B=2FOd2XfifL1MkfOobzrFlfWbLOI+?= =?us-ascii?Q?5OHMzMvbSCVNe0RO3lJkaw0lDdFF3xK16Be1htD?= =?us-ascii?Q?lDx6oQdRNrYNTZDchUx=2FG3KghXNszQ28Ktg=3D=3D?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Cc: Spencer Baugh , 64423@debbugs.gnu.org >> From: sbaugh@catern.com >> Date: Tue, 04 Jul 2023 14:46:36 +0000 (UTC) >> >> IMO the major issue with the Emacs UI at the moment is that it blocks >> too much, relative to "modern" applications. > > That is true, but it cannot be fixed by small half-measures. The > basic Emacs design _assumes_ this single-threaded operation, and many > of the low-level parts will simply break if the assumption becomes > false. Some will break visibly and loudly, some will break subtly and > silently, but they _will_ break. We have seen this many times: the > seemingly-confusing code which does things no one completely > understands turns out to do all that for good reasons, which only > become visible when we in our arrogance boldly make changes no one > imagined when this was designed and implemented. And people who > designed and implemented it, and improved it over the years, were and > are very clever, and knew what they were doing and why. > > The _only_ sane way of getting a non-blocking Emacs is to redesign all > of Emacs around that idea. > >> Some of this blocking can >> only be fixed by speeding up Lisp execution, but substantial parts of >> this blocking can only be fixed by making Emacs more concurrent - that >> is, making it possible for Lisp code to run concurrently with other Lisp >> code, on an opt-in basis, instead of blocking all Lisp execution while >> operations like gui-get-selection and call-process are running. > > You cannot "make Emacs more concurrent", not by and large. We can > make small improvements here and there, if we tread cautiously and do > careful damage control after each such change, but that's all. That's all I ask for, the ability to make such small, careful, cautious improvements. I think with enough of these, we will get to a much better place. As long as every individual small improvement is not rejected just because it is too small of an improvement... And I have the ability to test these improvements at my site (of ~500 users with diverse configurations), so I am in a decent position to make these small improvements without breaking Emacs. As long as I don't have to carry those patches forever... > If you look at the low-level code in Emacs and take time to understand > how it works, you will agree with me. (And if you don't agree, we > will have this very argument again many times in the future.) We > should accept that fact, and either live with it or start a > new-generation Emacs, based on very different designs. Anything else > is just lying to ourselves. I've stared at low-level code in Emacs a good amount, but certainly I wouldn't claim to understand Emacs yet. Nevertheless... I think Lisp threads shows that this is not true. With that as the foundation, and making incremental small improvements to the C core to increase the amount of stuff that can be done in Lisp threads, we can build a new-generation Emacs incrementally within the old. IMO the reason we haven't done this yet because Lisp threads are still very limited in what they can do without blocking. But we don't have to agree - I'm happy to make small, step-by-step improvements, which are justifiable on their own. That's what I'm doing now: I am trying to fix blocking issues which I get lots of user complaints about, not change things for no reason. >> I am aware this is a major undertaking, but I think it's important for >> Emacs to compare favorably with "modern" applications which don't >> exhibit as much random UI blocking. I regard this as basically >> equivalent to the lexical-binding transition. > > Ha! Lexical-binding transition is nothing near what you propose. It > changed the language and its interpreter, but not the editor and its > infrastructure and primitives. What you suggest is several orders of > magnitude harder (read: impossible). From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 13:02:39 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 17:02:39 +0000 Received: from localhost ([127.0.0.1]:36540 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjQE-00017z-Uo for submit@debbugs.gnu.org; Tue, 04 Jul 2023 13:02:39 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjQ9-00017j-Fq for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 13:02:37 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGjQ3-0007VQ-Q1; Tue, 04 Jul 2023 13:02:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=3ZPwl62PNh7vJVt9SZdkr9rZ96IFkfmSodvVA7tdanE=; b=cs+x5Rlls6Je 3SVEXLJQqxEjmZSXFSLLKW7f2eH8AJ9RaMAqcIpE5ffZc/MKg6uDEIhTQXYSSOK9iQ9F3wg6AJ/06 o+xIjmNUgmA/IRddNNPzcSdcvSE3DKpeo9omG6zepo6Id5S8VK4PUC2QCvbXXqFuC7ZcbZNwEoZi3 duIY0F+SUXD6VwP+WmxY28rnA2+Godz4ZIyPfJE0rJYKUO7hCBw4fPw2o4aMBjCwu2ykoEzuxMj+s uW5jUJsFgKQ0NhnLEQH44t1lUngNLX23Fz+ihl7EMHrTM76mN4GgViKGDnheXFzaIWuFwZFazVkDf gm1HDjUu0irDCuH4B2eHTw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGjQ0-0007KU-2w; Tue, 04 Jul 2023 13:02:27 -0400 Date: Tue, 04 Jul 2023 20:02:19 +0300 Message-Id: <83y1jvk3tw.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87h6qjoc6y.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Tue, 04 Jul 2023 16:48:06 +0000 (UTC) > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org > > Eli Zaretskii writes: > > You cannot "make Emacs more concurrent", not by and large. We can > > make small improvements here and there, if we tread cautiously and do > > careful damage control after each such change, but that's all. > > That's all I ask for, the ability to make such small, careful, cautious > improvements. We seem to differ in what we call "small" improvements... > > If you look at the low-level code in Emacs and take time to understand > > how it works, you will agree with me. (And if you don't agree, we > > will have this very argument again many times in the future.) We > > should accept that fact, and either live with it or start a > > new-generation Emacs, based on very different designs. Anything else > > is just lying to ourselves. > > I've stared at low-level code in Emacs a good amount, but certainly I > wouldn't claim to understand Emacs yet. Nevertheless... > > I think Lisp threads shows that this is not true. If what I said were indeed not true, Lisp threads would have been a hot feature, used by every package out there. That it is not so should teach us something. I don't know if you tried to write a serious application based on Lisp threads, but if not, maybe you should try. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 13:15:01 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 17:15:01 +0000 Received: from localhost ([127.0.0.1]:36550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjcC-0001RD-La for submit@debbugs.gnu.org; Tue, 04 Jul 2023 13:15:01 -0400 Received: from mout01.posteo.de ([185.67.36.65]:35223) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjc9-0001Qx-Ir for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 13:14:58 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id A278B240028 for <64423@debbugs.gnu.org>; Tue, 4 Jul 2023 19:14:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688490891; bh=B5FJ5wnVDzvZPLt0vts7QkqNUIf7XHj+mugjpPtEzAc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=ChNNwi892575MaJaCgdFJBCYhLXiLDqHvlotGWvBtUvyn0V7NK8k0sMQFBARQxkcY cGvGV0K13QHLIjpgn/m8QpQ+PSbsL2BsyO/EL2hT/cmS/nx532fsmW4BwosfLAE2wS Fn6WrPIlyaWQs1q9qspbK0EQRsGZ6hUbPYag1ZR7Jh1IfepEsuq0x+sedtEhMgY/3J +LzTIPscuI5b1GNVNRJBTjFaUW8cchupifcPXse2l6sxIHFrbc+A8/OxsdbKNN2bzp yn3maXIZjNxUGhCWbeVBlvEbZHVH49yvJUgZidSIF+S/lc9CJgBNzxPyYEr/Xa7i1B MrMonCSc2DpJw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QwTtD2mpgz9rxK; Tue, 4 Jul 2023 19:14:27 +0200 (CEST) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83y1jvk3tw.fsf@gnu.org> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> <83y1jvk3tw.fsf@gnu.org> Date: Tue, 04 Jul 2023 17:14:22 +0000 Message-ID: <87y1jvppjl.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@catern.com, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I think Lisp threads shows that this is not true. > > If what I said were indeed not true, Lisp threads would have been a > hot feature, used by every package out there. That it is not so > should teach us something. I don't know if you tried to write a > serious application based on Lisp threads, but if not, maybe you > should try. IMHO, the main problem with threads is that they cannot be "paused" at arbitrary moment. So, without sprinkling too many `thread-yield', any serious computation makes the main command loop unusable. Org mode has asynchronous processing since before threads were introduced, using idle timers. It works seamlessly, but only thanks to carefully balanced `org-element-cache-sync-idle-time', `org-element-cache-sync-duration', and `org-element-cache-sync-break' that limit how aggressively the background async computation is fired. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 13:30:29 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 17:30:29 +0000 Received: from localhost ([127.0.0.1]:36557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjrB-0001t2-BT for submit@debbugs.gnu.org; Tue, 04 Jul 2023 13:30:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjr6-0001se-L8 for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 13:30:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGjr0-0005nG-C5; Tue, 04 Jul 2023 13:30:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Z55bX9mVA+mdt3ARFB8o+qMI3dE5EGevJTE2qvf1rgE=; b=dqzQJvUPRnXl zaVUcJCDKP1SoiX8twvzJyQSkrpaM54Nw/O6OPy6JiP7TaLihZGFpyG0xzsogxonA/7dDqiUxqWum 6HKBPC9+jLuWHLtk7+L4/nRAqdg3NGOLt0sKNzpl7UdowpFkgjffzUFJELrDWRq+n21wHdeFN/H4x Fg1PoUYNHN5DWWgZWcD59ySwWbOCGBwLZQlzad4r/alTA+vSOj4FW2j71nvgxAPhk6uLfFie9KPnv rWsLjikKWPWPhfFK7bE+uymOXPF1zhFMMVtKSSqX2daScEXqBZRDrneul6tBQfRqMAG8+6j977Qit SRPsf1HyD2+MMfkDflA3Qg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGjqz-0004Rm-RU; Tue, 04 Jul 2023 13:30:18 -0400 Date: Tue, 04 Jul 2023 20:30:12 +0300 Message-Id: <83sfa3k2jf.fsf@gnu.org> From: Eli Zaretskii To: Ihor Radchenko In-Reply-To: <87y1jvppjl.fsf@localhost> (message from Ihor Radchenko on Tue, 04 Jul 2023 17:14:22 +0000) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> <83y1jvk3tw.fsf@gnu.org> <87y1jvppjl.fsf@localhost> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@catern.com, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: sbaugh@catern.com, luangruo@yahoo.com, sbaugh@janestreet.com, > 64423@debbugs.gnu.org > Date: Tue, 04 Jul 2023 17:14:22 +0000 > > Org mode has asynchronous processing since before threads were > introduced, using idle timers. That timers in Emacs work is small wonder. The point of threads, AFAIU, was to allow doing the same stuff as we do with timers, but with significantly less hair on the Lisp level. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 13:35:58 2023 Received: (at 64423) by debbugs.gnu.org; 4 Jul 2023 17:35:58 +0000 Received: from localhost ([127.0.0.1]:36561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjwU-00022T-45 for submit@debbugs.gnu.org; Tue, 04 Jul 2023 13:35:58 -0400 Received: from mout02.posteo.de ([185.67.36.66]:34951) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGjwP-000227-8D for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 13:35:56 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 4312A240104 for <64423@debbugs.gnu.org>; Tue, 4 Jul 2023 19:35:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1688492147; bh=fK6UmkiwurNoDx8oNUQX2I9vp3uyLRUOpr00rxGSVLU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=V2jt6kUVbXGKWwk+pTjNyqEHNmAUWPEbwyiXOmYSpCgNfR1xO2zwRW7rwbjlBQMQG kQ82vCLBRTw/wWKqtDtBv7W5m4HoJVX8k8Jx+qctw0MVmUPRSM6LfVftIs/A7l8Rij ngJiZtKt3n28Bfh53qDq6Wux3UbLJM3GED0TUAhiUzFOdHJtB+SuGF4xCUaJ1pBpUM Euup3YPb+zzArP9C/s/7J2Y3pg0MKZw13fZuVWYEbgvA5F1YHtBUW31vBPbxcTm0DV XT5zlAJ8QY8/57dyKRWo/8wm9pHoh9UEUYs4bA0T15NJlxIdO6oLxqS2A+azTP4DCz DG5fAji5Imzew== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QwVLp3J7Zz6tsb; Tue, 4 Jul 2023 19:35:46 +0200 (CEST) From: Ihor Radchenko To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83sfa3k2jf.fsf@gnu.org> References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> <83y1jvk3tw.fsf@gnu.org> <87y1jvppjl.fsf@localhost> <83sfa3k2jf.fsf@gnu.org> Date: Tue, 04 Jul 2023 17:35:45 +0000 Message-ID: <87sfa3pojy.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@catern.com, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> Org mode has asynchronous processing since before threads were >> introduced, using idle timers. > > That timers in Emacs work is small wonder. > > The point of threads, AFAIU, was to allow doing the same stuff as we > do with timers, but with significantly less hair on the Lisp level. Yup. That's my point - thread can be useful, especially if there is also some boilerplate code provided by Emacs that makes threads less blocking (read: trigger less frequently, and stopping not after the user attempts to trigger command loop). -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 20:19:52 2023 Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 00:19:52 +0000 Received: from localhost ([127.0.0.1]:36830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGqFL-0007VU-Ns for submit@debbugs.gnu.org; Tue, 04 Jul 2023 20:19:52 -0400 Received: from sonic312-25.consmr.mail.ne1.yahoo.com ([66.163.191.206]:34034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGqFJ-0007VG-J3 for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 20:19:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688516383; bh=DdHFKryQ/ArOwaMRbmAFpDltxkSE1Plgor7n9xgWkqU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=eQ9xl7L4x9jzlU0CJ4L4fTeuShp7a71o4NeLOtL0hVfprZrZlrgTSsIu+1urDE/85AZGt2hGHwbAFkI01qxUwyXx6xMxUQFe61gTBb/0wG5YIC3kBcYA6bgr9U27amuIjAcKY4N7v8jERy2WexGJMLwBaoH2giyDx8peVAB8H4Hq2fAHUrWxzz+avCYio91F0m1H9t5hhXPUegUXOQNbsZpj5KZmw6HDgMdeTgmZL5ZJd/ZfvxQdnpelddNlQ0hfJpC7BPU3fOogxAgmz+oh9VzoZAK/BsgvfZecguKjLKbuSfFrP8VimZVTfb6swdLMWAS2bSDcsp0/a3omaRM0DA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688516383; bh=COGdE4J7i/JowbiaIr+B1BVuYkO7paOys0ml3mgF0z1=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=FW3RXUpd/yxQhxn6AkLdX+wsrGO+nehlnL8ueN2mjwo0iq4tD6KqCSTZcIxlvd6MYbejJR/Qb/E3tvX4gPaGjFruT6XoVPlFRZuGWy8ELtdmwsAzJjFMKUqapF2m4Ez4IxKXwpjC99+KvQyTbjN0S1LVQgMamU7vNW2brYLuEZ4xWg7o18TLKp2fSLJBZhpZoyTNYu/qSlS0WHkVScqR8+Hp/DHU0v4KZk34FSyzgCjHAfN2r69FM52iSG+DcHtoAJnyF//uEI2KIy7Tz/V40F68BT5IZBBS9S86ss/SNFmb/slvKa8auLf5W0Fm+sOjnK+CXAputEOqa+aWFmK44A== X-YMail-OSG: UIDtG1wVM1meeEWNQFdZJfBTOX0zos2sg18kUvrthSkMp_dmMAiOZ3AbAKCVT7K beb_tR51tiiAVLN.5y5JT3qwrmMcgAvFJEnSw2grIHwT5t.RkwO4sZ7L3ygiIDdEHQW_Vr26o._v 9xW34l9NEIeNlpPBSLqKI4hti4S_jg9XbLVD.oEOwV5aEWPL5vAFIF5n0Lpeg2ib.mlGeoWP5Q1z YbHa0bBMCJC74e3h611UHOagTt4z3gpIfF10mJZbC.I6kk7jVsC6mUxqgPx4do4eM64eieMbYP6C ImEB.qkhuPDrbXdnlqFnt5qzveWxgawKt0KlWbKV_15lyOYFiHATUR5MoFvn1rTHBjubW2LWx1rE DtPDbuHAPGsfIK82S4B7eYV7WaoNN2WqzPm8mpNfkfXvCvLFFJSai7LMgV3_sAu9vwWjxWLM3LLn 7uOq9AROC7Rcxt0pc0EjXiM5gOM5iHLiPd9mkaQ.4wjg1UGiqzjMAAV8P4y2t1LIqVkuDuSVljN6 CMHKlftyJ3lmdKy8aQ625ZNPWe9jOGT2V8hIKP9vXQuOwSoaFVL_pyfyzJI_5jY8kVfKO0PufYct iO71mgZaH0bFEWSJhYpzmH5Pfv2JT7YfvXp9w_do82dpIQiLTU0_GFfxNtIzc7wqvAMqHXhviRNS aC7G3eOmID60LDtTjFQ66hytMQ0S_g8O1i9aPEpU_aivgdJWWv.rQMdQrlZhPHMrQcli1kCNNds4 mz7l2a_pr0uspFpZZQfqog05fZBtp9CxUWlcLzlBgpMt.1h4hwdaHglJWDTdosPe79HlI.4lUVJy quWFbR_b29aOKV8YNuIigvH0JiMl1vVYVpTvKyFYpt51cC7BFBUXIOGr9yM2QuVwv6CTLJ93e1mN .PcMgD0M03dRjAzz1uA5DzU6mtGqGV6gcM0k3OxZkG6tlHCQ_wKnRPuaGp.Q9QgY9hrNbwpiLHNH WVvDo3P_8AXMdmOKZA9Ca8OcevGMZBCIoHoo.Q17qb6gulWelykdJ0TJHpGtCK5Hyw5QHottAFST eC5YKgTRMitECwuWvDoQfkWy0q6QsVVH.M05mSMZxpal19XAmtZe7IxCu6SoSIZm3AuQmxspAgC. bPMdISv76PRLwGqEQLSGwc0n9tVWDF422E8fzNEyeeWHLymGmsCATRYkBYycZdgxdMVqdehgY9DV TBYB1qECz_v1rdd1zFtO8Nf3vrVCFG2kcPRt5x_XQIUoFO.gU6ig19dYbUS5DIsbhqU8qm1M4bKJ z4c3x3rhE6E1Kfq43oeeHK6ZqfaIX4bXA1PGIof2k6Z8v2tOrQEhpu9ABtQUXFXasM09MQWwYYnf Pkq01BFEJSmbzk9k8ZynVlq7Rsz6rdwrAcKhqIgTFdq8DVcw43RFOM6_KRPC7X2IzLDnIvKVS7rF ChLjfWDqtsy1sGfeClZJJ7eQrBmVtS.QLDeMDsr65FKoYso77DlMcoDbil8E1BWOHCbrEIC7IOyi 3a32cSOvx.yu.DlExAxfwvjOqa79ptyfTcm4K6KHevmMkFxyKMAW9LAjSt36UsYMYvHxEhoRStx9 S27hzcHU3udj_gPskWn_EiXzU7kNitWnbDZDGaLDTdbGOIzoNAJOVqaxlZlLrbBmhx2ZSqqN6eJ1 OnMWdnnjkCMsUG3naX7HV_yXs7T2ppfnWjy1zzMA5UcEpq8DA6kv1DC8fq35Sf9pwWXY6hrbjEz. t7zl_AgZ_LxxcPCT5ov3_sAkW4hA2Z2.0UlBY8x3S_aTxfcFJlhP7DL20utP18jz9oRnjTbf8Vn2 kQ5fzG8seBJR1KVM9gt9QRY5DbLzvynE.pJ3RMQbW6dBmB8spVEUxhfVP_5JFTXrApww3c8LpZjm kvbLh5K0gU4R_sCJHB1WRV1Duh9i1fCnm7zvjlsjd0uPGjhncbk0Prpl0XVRCZDNHoAmyht9I.bF AcWX0MM988nXNHa14JaZHJUwrWXL7g_hZWJM2iW5.PcH6E7Io62TGSeWKnET.awVrAqo0109_QkF k2RddbZCSm7xVciEAD1nQ.smRnn3TvMZFoUWlmuosbkWytnA6A_vGc8SGYUZCina1LJvDn7621q8 efviBirDw6_HpfGmHcz4j8_rLAHwaLRt0xMzmzZVMvUvzd2ua7iGJyHaq2892pg8hv19CrVzoko8 cdQH9ZRZNan.85N.biM1rFENWoF.dar6ou2dwfthXOcta1TmXRMbSrexd6BnSeLJP1i0AOMCS60d e2b.wOhgq00ZHGhRHsEWvGavyo3XL5zd7z5kVkNc92El8GCWAQgRkMJ7opoe5ui070w-- X-Sonic-MF: X-Sonic-ID: 53fe491e-66bc-4145-8c27-c5f3ae18ae87 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Jul 2023 00:19:43 +0000 Received: by hermes--production-sg3-67fd64777-z82qw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a00c8dd67d69e590a1dd705d03ede441; Wed, 05 Jul 2023 00:19:36 +0000 (UTC) From: Po Lu To: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87jzvfohtg.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Jul 2023 14:46:36 +0000 (UTC)") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> Date: Wed, 05 Jul 2023 08:19:31 +0800 Message-ID: <871qhnqkfg.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2687 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) sbaugh@catern.com writes: > I think you might be misunderstanding me? Just to say again, in the > normal case, this would not add extra cost. This would only add extra > round trip cost in cases which, as you say below, currently just confuse > and break Emacs. It is extra cost, for an insignificant problem whose fix is unwarranted. > (Also, the entire point would be that this component would move from > being synchronous to being able to run in the background, concurrent > with other things.) No, setting up the selection transfer will still remain synchronous, and x-get-selection-internal will continue to block. > This is becoming tangential, but, yes, I will bite that bullet. "while" > should also check for and run timers and selection converters, when Lisp > code opts-in to that behavior. I can think of several ways to implement > this without hurting performance. That's unsafe, and that's simply not how Emacs works. You're talking about turning code utilizing while into signal handlers with strict reentrancy requirements. > IMO the major issue with the Emacs UI at the moment is that it blocks > too much, relative to "modern" applications. Some of this blocking can > only be fixed by speeding up Lisp execution, but substantial parts of > this blocking can only be fixed by making Emacs more concurrent - that > is, making it possible for Lisp code to run concurrently with other Lisp > code, on an opt-in basis, instead of blocking all Lisp execution while > operations like gui-get-selection and call-process are running. Other UI toolkits also block waiting for selection data to arrive. They even block when responding to selection requests, while Emacs can respond to multiple outstanding selection requests simultaneously. > Here is the real-world use case: When I yank I'm willing to wait for 2 > or 10 seconds for the paste to complete, since the paste is what I > actually want. But when I kill-new I want to wait less time, because > the save-interprogram-paste-before-kill behavior is just a nice-to-have, > which I want to happen if it's convenient and fast, not the actual thing > I want to do. Have you actually tried setting just `x-selection-timeout' and found it unsatisfactory? >> Let's not overengineer the system independent interprogram code with >> X-specific options. Thanks. > > A gui-selection-timeout would be fine with me, too. Maybe other systems > would benefit? pgtk? No other window systems will benefit from this arrangement, because their selection transfer mechanisms are not interruptable. `pgtk-selection-timeout' exists as lip service to the GDK selection mechanism and doesn't actually work on Wayland. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 20:30:30 2023 Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 00:30:30 +0000 Received: from localhost ([127.0.0.1]:36836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGqPd-0007n1-Vi for submit@debbugs.gnu.org; Tue, 04 Jul 2023 20:30:30 -0400 Received: from sonic310-25.consmr.mail.ne1.yahoo.com ([66.163.186.206]:38894) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGqPb-0007mq-WC for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 20:30:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688517022; bh=NPQHzk1jACvT9EpxAnpAS2YmFJSCi49+7uljtP03om4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=mT0+4NucTkJjeA7yBvXdWups4OyYBZZmaAXKps5LnqFB9Yn+MJBL0HbY+rDNSzHsbneUDLC3b76p55+4xEb66uTY4Fr5JSPrXqQAhyjHgz/MxM0uYsXOuZHKD3ftytjXuNFUPRw4T/JmO/HQVpOuy70I4NT1wwc28csQ7xLSdt/mBXTohdWqonfkRhBk+How9BWvMn6xinNkMER7f+qGUiahbIij41gcp8Q1ItBfX54sEx2puG8NE1oChOS8redkcZ0nG+s4xmm/upZ0TL9QFBFJqW+x2WWaCm2iSzOVFXRCk/RItIQBnJp+tQVkTJYqn+a1c0aOtcaenKA8ZEJGCA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688517022; bh=H9CNKLoe68tbddBNlYGKJWBxOk3+tHimJDQBeZTdcdo=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=r4MAsqjSCKPce+uYsg1ihoH8SMpFKEszwZJgfAWQAB6/oziOSGD+ObOo6DG+BlOvz9XajWjWglzfkUay2va9QWlfUFi2oW8i2pmAFQL9uMQW2urBz/ZHNsMvJXNwLjj6fkbMR6rJlgS3g7yl+dCwim3u+pGVDlL9LVHIDzKEpIgXEXN4YX3aWbDiuSFhnh4N59xN2pFgM44RC1OkTxUUQmlmtMqNKBY7CyiOB4Be/S2Md1IVo9l8SRVFGzEm+OrCI3d4XURBGR0VPKOXfnG3Y0d2AKCVRzgZec0Uk7EUVgGhpI5srKIbQav5VIc3f8IbktFDIGmRKRhrlUNYo/Yu+Q== X-YMail-OSG: mEpENT0VM1mlgfFZ91X1MEQ6ir.OYd1UUfbb9EucAhFPOzxT5NzXluwjFWkZNdM 2kmAVOhPSmPXwtOJ9hHUP1gFkDVWwmndnqriLiycr0lkBV6SJe4EeHl.kmmQkYFzG6CybLM5aQTb YqlLOndSKtu1EIl9utV5KKXAIPqSi3U5K_T0QE4I9cAxU3HwYrICXL39Ptvk0tpi.ct1TyywemQG tMaCx8OK87iV9U62HefK1wuNocNzgHorfgB178YLFCGMMj5SRyG9SBoTwjafvvOyUzl2.haLEqoj FHR4nlrzFrWb1vQQRUKsoUx08xPXntZLep7_K45yUCjqOYC7CFiFKog7Qwc.v_VOkEIpyx8BRS0l 1qYZ2KXNdj2ndmhz63eyURrPwf_wovFXgN1Q0PDOx0nxLdZxxBR__d45dWDKeest8cQQ_iRGZYKm Ik.k5KSIZr58wbpHb.bk5YDaEx2VtXcDg4_cxzuns12LjAV2ClVA.ZfxcHhHYyEAuGddQTs6qn1s xOc2hWyCsoLiGxN7xnUc48qhirCb6LjsOLA5j3ULYQD4d7Fp8obUGSSpt3ucfLPfADPxnCeIjwyy 8f.r1J53jxoipO2aCZM7VSgFBEkCpf4d3K0YBDyw_7RKsfXhZSw.qHXyiagQW3gJZrR2YOga3H50 bXl5tVrMaaW0KdUOxPcH8TiFAlRRW3lRnKzBrlwdxA7bwVl7UU9IeU65kUHEbYcdlncAvjbM7FbR QZZv14V4Ei2A92wNOuLb1zRDMFEy_0PM2xa7k0gCNDqdyqVLQK1gUbR1GK7UJzHv.Q.18PQsuQcb nuwdcxKcujzN0Ck2PcNbx0Q0fgBHvCt4SUOlb8EUpUzbmA8Nf3YASQ2CoWPEWDGkkmlNIa2HlVnG YLmf.t00IGaK4F46xYGYBWVfk3kEPH5Xli0rFJEuY3TLcBeMP3g5D2fHFSsTmCnSdUWSVn21eAPX 4_XnJ0s2DWQ2YVk9PZcTLACEtVcvPFdZ0484rHSTrHz_3A34nPwf4UvSfIei4AnsDwk8vhmpYnjq UXtE9gkxegNXox0hHsda.jnmGIQzO0KUVFPXVugMwbl8eRZJheWyYxPneoBl2bxhutiiIwoiSvpT SfEN6EgrrQuznkCrqxqtowpJuBkl3SEJlo1YSwNMs6vfR0aLEeJNjTrn.7m7OFYc_mMAPKC6iNaB mCIRwhnnIAZvP8XVTpLHZi0rPK6d.GBev2xt3Ux8qIL.3_URQJfytDJ.cIqIr9jgtzzPkVnwWkue FoOad1aE5v.f1Q_GEXWCKk5D2rUxYePoUymzlzUT7QOl6lF.cjOUQy4dadQ8py8R2je9Bni1iKkI sN2MIzTeiU_0wM6.FPo.kJAJC0cOtAhfK9uFndhq9G6.wD_RP88L.iCPUL9ycQKznXniYdyKFe05 v22wfSxoTGq1f7Ov8VCQj67CO3tysvfsHhxYNM05WFDSPi7WOLq.q16wGrdr3ICJ5opLcfREsCCY lbNPPa5hFs.sC7TptvIJ5q69NaBdATX_FrPa2PGvCjoHxPwtSSvWgVlZx270dh2BdWAnUbX986Mb frvme3Dvnm.dotWVRBOsN86wa5Rz3Yr7vQ_uSQjU13IJG3HNOXCXAacLVH9On4.FCJHBxrfm1zaZ mLzGS8eOvLiLbk.dZzmZkKjPX_GjruziYnOQOt2ckAa0Ygmz1_gpTrOw4d9yHi_znLNMjVtu9m6C la_vFDv.dCObY_.I2W2Of0XHqFNMmpaC5P_XInzO9b6bvhE1.oUW3djrw4pye9ZvFvjCRlCSeZeP ApUQRJacw.n.dXkLaeW1mA3iaoHKGUzd4uWK3HWFficOmfEA4kjNCg2B6TrHQ86lZNn0JyxUsxJE 6b0QTX2bD9KWJbDvHrqMvjehIUaZoNNpqrKZ2oYUkYljoUrFso3AG_gnY1G2MVAwfrRQputmtOZd vTEp62mO2bDtBK75.H.JYVtDbPL.AVowzqJWvVSagL_XYfMJeY7iTGpmqOgMF3Qiq27.C4ITxLwu aDBgFcUob7s8c9iqrXbJmFgSuZzfWT9uJYxMclTGw3XBO15yOKJC6ZTEL359RaZvlnurBRUiSM6o lmUdh3PjRo05CYplrE8E9WCDoU0B6Y2RoBohXgqwWZ4T16GrVNyTeEVxSAiehMINwYGVFEdO_neq xqGu0WJ0rVOyozxP0b3LHhEjAfWbaozSbAScb7W0MDm7iieiH_qVpZ6UvnjFnrOhrkGmL5G_RMLX _atGHEJTBBD3NONDgz6aL52PKP0BfHoBk31P4EaspiBh4d6T2_FSfI3ksQVhgtdjJBPw- X-Sonic-MF: X-Sonic-ID: e6624e8d-ef38-4d30-87fd-4cc5b68a6d40 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Jul 2023 00:30:22 +0000 Received: by hermes--production-sg3-67fd64777-srcqr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9717e8bb7ea101a89fa24c48a6ceb8b4; Wed, 05 Jul 2023 00:30:17 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83sfa3k2jf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 04 Jul 2023 20:30:12 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> <83y1jvk3tw.fsf@gnu.org> <87y1jvppjl.fsf@localhost> <83sfa3k2jf.fsf@gnu.org> Date: Wed, 05 Jul 2023 08:30:12 +0800 Message-ID: <87ttujp5d7.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 349 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, Ihor Radchenko , 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > That timers in Emacs work is small wonder. > > The point of threads, AFAIU, was to allow doing the same stuff as we > do with timers, but with significantly less hair on the Lisp level. IIRC idle timers used to be implemented in Lisp, with an asynchronous process sending output whenever a timer expired :-) From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 22:30:11 2023 Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 02:30:12 +0000 Received: from localhost ([127.0.0.1]:36885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGsHT-0002Pb-LI for submit@debbugs.gnu.org; Tue, 04 Jul 2023 22:30:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGsHO-0002NW-Rv for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 22:30:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGsHH-0003Pk-Sz; Tue, 04 Jul 2023 22:29:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YFXM8AjQ/xAcBCUQAmwbeZp1qpb7heYxfKzpo4hq0t8=; b=sgHH64MjzSEe DmVlbN+n1SL5GeaFyO0CDTl2iWONbqsZcCg0CwFZ3+eC3UvMlSfz6Lr51wRHMXulR7OJ+cSGeoe/a BfSdR6jf7kb3E00VtTjgNt4X2hNZFGDM3xMTHP4Q+WhFl5ClFp+DAP2j3EXAycvcgIDTeKtu3389M 8N/idZ3CmVAQpTU8xrqWv4bWH9Iv1UgbxRaf3sCvob0JW8X0FsfptFhXe2ag+yH8lgXs/AMw8kzXV FemvGHpFWiYqndbCtAV8HGrnKb24cL039BqEYEJptJ5T8GipQslsYxaBPJm/0NHNJDl0XFiMiB7VT 9BkudGMS+q7+WJTfLNBm9Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qGsHH-0003b5-Ck; Tue, 04 Jul 2023 22:29:59 -0400 Date: Wed, 05 Jul 2023 05:29:56 +0300 Message-Id: <83o7krjdjv.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87ttujp5d7.fsf@yahoo.com> (message from Po Lu on Wed, 05 Jul 2023 08:30:12 +0800) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> <83y1jvk3tw.fsf@gnu.org> <87y1jvppjl.fsf@localhost> <83sfa3k2jf.fsf@gnu.org> <87ttujp5d7.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, yantar92@posteo.net, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Ihor Radchenko , sbaugh@catern.com, > sbaugh@janestreet.com, 64423@debbugs.gnu.org > Date: Wed, 05 Jul 2023 08:30:12 +0800 > > IIRC idle timers used to be implemented in Lisp, with an asynchronous > process sending output whenever a timer expired :-) No, _all_ timers were implemented like that at the beginning, before they were rewritten based on the Emacs main loop. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 04 23:51:47 2023 Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 03:51:47 +0000 Received: from localhost ([127.0.0.1]:36957 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGtYR-0004Tv-14 for submit@debbugs.gnu.org; Tue, 04 Jul 2023 23:51:47 -0400 Received: from sonic309-22.consmr.mail.ne1.yahoo.com ([66.163.184.148]:38722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qGtYN-0004Tg-De for 64423@debbugs.gnu.org; Tue, 04 Jul 2023 23:51:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688529097; bh=unDYjrUuHlhJtN7KKD1u8dzg/hou7nTKKZbw6xq8HbM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=r9tJvo5OlOhxvVkNzQGKDXgzNeZosibp5l/2Wv0sDnk3dvwJ4NYu17rS1zR7cutlm3o5TV86ZLRG3GC/eRcRF3BwBvpxzxoCpXWqhIX+HyOsGsHarKPxit3Y4ciU7TZIdkLvnA1pNxFp9kS284Q6GvEvSnPFauJqWgGlY51czLuLYMzBCW/Pi6VxO01TMlZPH9C3vkX8nyGGbteErxl91x7ivD3zg5akXNHb2Lvgvr5jbeK61NWB431m8ZJB5fmFouajOc7XM3YTHQe+80KbU8/GKhXocl9sMOkqYTidOhXK3qHzLyySEgBcRHRHwryNey5OlfYnTWoxaDKcPrc3Bg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688529097; bh=TR167opJQVEXnqW25BWz30y8uPsNfGlRGmVGUfFivRe=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=fQ//I41bka2GaWc3K9WFbqI6vxC+YSP0794kola+GCcn+cFbr9+r3GkD/Za1An6qL96v7ShIZQ+J4VHM7It1XTvtTRyzNqNdPXU1xwKcpZu3ONRHfkzJid9WSA/0PTCx7PZYWILwItkNbkFwUbZzeiS6LQjZzsWsBR6lASrTfw6iRFCocDg0ZYjIzKs/37VQHvHAp1D3x+sFlLdHG7zIa2+3QngADHWtOs+OOs1VQWyxBw3RyHp3wlQlN5S4w350N45oTtv4Gfq9r+smAUGUmAjF+BQPnwMW0Q+Q6+U2i94uPRkg5vb1n7DSy3bmORydg6lScyMa9hE/TibkA9vIlw== X-YMail-OSG: iqyZXQsVM1nCSVqv5HJKkqcybvly.N3KyGDPpnAcLSQCk6uAJpnvAcDoIK0uEPX UzS6_L2eKb1Pk333ExUfXAyT4fUFwi8ndQKRJKxiIAKDqwgVLx9hpfolPN35WCypebRHqEn7FDFB 6Ecqf35S3woaxIyBgbeZSB9XRtjo4dQ3ojvJpHjJxiMUMTxff_HBcREUnjKeN5TTWsLcFS76l3HR EgJiIcxDVPb7ukMM0eZvwrb94Oj0NfA4yehXYp9dPxRvw6Fi.pcWQk2sEZ1dHYMsbkgDmMiP5pjV VqjP.qsXy2Z6ouUiOiXRiXpO0PLlI.shy0RUUrQeEO0lDB62JtneVYehZH418nmIRuCL0.ty0wvF eBmOz6DRUbaIdF2KK9TYr0z0i.OrWX3Sapfk0me7exthNjWIb0p3eaaOZUgSnsXdyJw_2FaLAguk DpKV4GG7qgugQHGjiAdZZoZQUM490yuX8t4KowQQ17_6EWPH1ttAKhp2Nt2NCW3clyiJEwLBGx.y tgsJEJhafLRL1kPjxFZzVeGCtU7psXFLUJ__NbxnWdMiGCRp66vxCUKL5YiuAo2RhridyAvwRPU2 1RKuGhchyJHNVhW_RQe5p5aolBKb9p.LWyhJCr1yog0FoQ4MN973g6FzXDV92KAN9OIJTg_F8X2v PE1UQOO1rTSSd.f0dYjATzQzrf3ssSS9JZDRfTl7cXlQG3d5Gkc6pC1CUXBGxtDRIl5Azf0h2mKS QapozD_BtIwvdDlF6OdKlW8hRl5BV6WoN9vAk_DuMh.uEYkR_VKyAO5AkZup71VGj3SQTdeosZvq 5rgZjp8E2t1EqpNg4qEmADJ4Ew6WZQrNe5PibDtUqJ.lxzkJHoaYablRUcjUupuzbyzyXgzuX70L eck78rdPlZA.2Y8ZMgxNn6jtG6G6qXRoGU9VZtlIzn9.UfAlfxYKvrOoTiB9yokc6v0fixcDdYLC vCrYzSRYSe23yt1tLUnidggbYdPwmH8rH_cuesXtrAVKTCRkKDLmTxKuwmkg.DoYkBdZ8F8qFp8h aMAIW.sWwHftc1fF7MlJH7o4E8TUxoDnuZ5NLJWnzUHO6dpDvivwM72cFMFfCOAog2X6dEHFNvGV 2s4OZVxl2Av1IoqYRqwjZ3cVi9HdgezJ3a1lRjeBQYV6nrYz7TP5L5VyX1cIX_nTetRolS0Eifyw SBfZpY5lPOtQiJ7qKLbUPZiGcTZAmQoFaX8pcCwextujZ4f6GbkZoIKOYA.vJSgC507M_UWACRzF 7ZAJwzZiXus8DoaHafgBDT_As6XfFMY.Z6rvePIgGD60PED4PJaBmyqurvt3gOjo.HEzYvmpK_2J g5ZuqQ01RmvKBQy_YvAQ7QRExFoUbuuzUxU_cRbIMNNMGFvpFSryiTC8khn95lXKHleOa20psY41 6SiJPT3PMk13TszI_NVw5GTIZ_IcbYZDDRW3wGbOBq7y75VyP70HPgQraOvBNchoxn96Sp6sLDNt DNFXK2igrJcz.rO4QxpejPGFX6erGJ6.ZAWwAnX9db1XctXI3Tt2iVtKAJG5uk2o_8Iz4_3P_wB_ 2cW8cGfOtptfsRb.6E7IvuELDVc66k9FlQ8xNla_7qOrFBSnHtY4rJUAKsBynzxb8ZmJDQZtyzP8 kq08D1aaDVVa.xD0ZzEGyaei66D.hzt3EmybEPN.3391El9j6_S_IePv9WJSDTgpnF_kHgKYVUb6 i1IxRJFWPpB87uTga56GcsXs9Mzd24_jXjwrjSmco.kMDq2rNpwa01FneMzDHrbrXTqvdh39MkTX 3xADoij5tZMsAUctXwGPyIj90mTIikfGWkYQvtGox6uLb0NIglOCl_BtIbK7CAL.6rg8AWXYkd3g cSI8FaqV7YZ9Dt30dZR2EfyrZp671cEurjuQSk21A3OgHUZwIlU0SV9d.xn9_pl23cc8SnMloLWd KXnQ30qcNf5gL_cVF2QqbvHds7G27kmO4XshYNbd8DsPcmKoBD9dGvAEN7kHpZPtcAZnSQav_i4U .R.YnBAePh8Wqbg4KjanwZ_3dupA4KZVbZjQ9uGlSgGcLkmnbqrzG1PWBTAdU6KPU.7r3BGZ.D0T eH2_hXp4XRI2jta18yAptBnpQLw8EzulFfOZyVS4zxAoCf4BLUKnugyYZuH2mUpYtZPW.RtEDKu8 Rmr954yKnXfZdzCrCsbXrRuFDlbNoJ39C1RTayTZxYlTn2NSCjERDQCyKTDVE1Faz6jUTF.Q1jjn tDEjP1Xc0onIHRS2iGxvBOoKjnvWQTMzfnObstVewmaH8vuT6lu8MSOkE_iJPa1Eld6GKwuP1 X-Sonic-MF: X-Sonic-ID: 10ff65ec-7dad-4698-89fa-50427add817a Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Jul 2023 03:51:37 +0000 Received: by hermes--production-sg3-67fd64777-lqw65 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3e2d211eefb8e1b7b59f35e465a7ca62; Wed, 05 Jul 2023 03:51:34 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83o7krjdjv.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 05 Jul 2023 05:29:56 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> <83y1jvk3tw.fsf@gnu.org> <87y1jvppjl.fsf@localhost> <83sfa3k2jf.fsf@gnu.org> <87ttujp5d7.fsf@yahoo.com> <83o7krjdjv.fsf@gnu.org> Date: Wed, 05 Jul 2023 11:51:30 +0800 Message-ID: <87v8eznhh9.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 198 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, yantar92@posteo.net, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > No, _all_ timers were implemented like that at the beginning, before > they were rewritten based on the Emacs main loop. That's what I meant to say, thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 05 07:27:50 2023 Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 11:27:51 +0000 Received: from localhost ([127.0.0.1]:37238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qH0fm-0000SM-Im for submit@debbugs.gnu.org; Wed, 05 Jul 2023 07:27:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:42562) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qH0fj-0000S2-S6 for 64423@debbugs.gnu.org; Wed, 05 Jul 2023 07:27:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH0fe-0007aC-0O; Wed, 05 Jul 2023 07:27:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=eMiFfxYuHS0y11ENvqw0EPHYr+Gzruu/BW2LaM9APWI=; b=G12PiF3de4Ta ZDWqOMC5SfUfJc8hLpYL1muTNUc9maI/NlFMPJPsYyWqGNdd31Eyf2nTPAzybl2uIBsLCecy5SoRT AV/3SFwXJajXXAx3qEutPD50Jbsie17FYsKU7YNgF4Ff84+zcGxA4I4FaxxcEoOk4JB1DFygv/T+6 avr7kLiK/s7HtCRIjeVmnLOgimNcnXw396BLdyRZnvzqDcTKQdCqMi217mmmgKHRf7hWTOfwN1tO0 CY3fX/9JoJB5SrV6RBfxBs6lOh7ooLABxMf+1btZqNQR1X/SelmtbkKALazvMM+e7waiMRwmU+M4h J3TJS/oYboroT5edCeKmOg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qH0fc-0007Kh-UJ; Wed, 05 Jul 2023 07:27:41 -0400 Date: Wed, 05 Jul 2023 14:27:38 +0300 Message-Id: <83jzvek385.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87v8eznhh9.fsf@yahoo.com> (message from Po Lu on Wed, 05 Jul 2023 11:51:30 +0800) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <835y6zlkf7.fsf@gnu.org> <87h6qjoc6y.fsf@catern.com> <83y1jvk3tw.fsf@gnu.org> <87y1jvppjl.fsf@localhost> <83sfa3k2jf.fsf@gnu.org> <87ttujp5d7.fsf@yahoo.com> <83o7krjdjv.fsf@gnu.org> <87v8eznhh9.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, yantar92@posteo.net, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: yantar92@posteo.net, sbaugh@catern.com, sbaugh@janestreet.com, > 64423@debbugs.gnu.org > Date: Wed, 05 Jul 2023 11:51:30 +0800 > > Eli Zaretskii writes: > > > No, _all_ timers were implemented like that at the beginning, before > > they were rewritten based on the Emacs main loop. > > That's what I meant to say, thanks. Also, FTR: that special subprocess didn't produce any output; instead, it delivered SIGALRM to Emacs. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 05 10:00:00 2023 Received: (at 64423) by debbugs.gnu.org; 5 Jul 2023 14:00:00 +0000 Received: from localhost ([127.0.0.1]:38747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qH332-0007Pe-DE for submit@debbugs.gnu.org; Wed, 05 Jul 2023 10:00:00 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60505) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qH330-0007PR-Mx for 64423@debbugs.gnu.org; Wed, 05 Jul 2023 09:59:59 -0400 From: Spencer Baugh To: Po Lu Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <871qhnqkfg.fsf@yahoo.com> (Po Lu's message of "Wed, 05 Jul 2023 08:19:31 +0800") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <871qhnqkfg.fsf@yahoo.com> Date: Wed, 05 Jul 2023 09:59:53 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > sbaugh@catern.com writes: > >> I think you might be misunderstanding me? Just to say again, in the >> normal case, this would not add extra cost. This would only add extra >> round trip cost in cases which, as you say below, currently just confuse >> and break Emacs. > > It is extra cost, for an insignificant problem whose fix is unwarranted. The insignificant problem is Emacs potentially getting the wrong selection if we interrupt an incremental selection transfer? I'm confused, it seems like that contradicts what you said earlier. If interrupting an incremental selection transfer is an insignificant problem, then there should be no obstacle to automatically interrupting the incremental selection transfer if it's too large. >> (Also, the entire point would be that this component would move from >> being synchronous to being able to run in the background, concurrent >> with other things.) > > No, setting up the selection transfer will still remain synchronous, and > x-get-selection-internal will continue to block. > >> This is becoming tangential, but, yes, I will bite that bullet. "while" >> should also check for and run timers and selection converters, when Lisp >> code opts-in to that behavior. I can think of several ways to implement >> this without hurting performance. > > That's unsafe, and that's simply not how Emacs works. You're talking > about turning code utilizing while into signal handlers with strict > reentrancy requirements. > >> IMO the major issue with the Emacs UI at the moment is that it blocks >> too much, relative to "modern" applications. Some of this blocking can >> only be fixed by speeding up Lisp execution, but substantial parts of >> this blocking can only be fixed by making Emacs more concurrent - that >> is, making it possible for Lisp code to run concurrently with other Lisp >> code, on an opt-in basis, instead of blocking all Lisp execution while >> operations like gui-get-selection and call-process are running. > > Other UI toolkits also block waiting for selection data to arrive. They > even block when responding to selection requests, while Emacs can > respond to multiple outstanding selection requests simultaneously. OK, so we are doing at least as good as other toolkits when it comes to retrieving the selection. But at my site the UX is still worse than other applications because save-interprogram-paste-before-kill makes taking ownership of the selection block, while for other applications it does not. And save-interprogram-paste-before-kill is a useful feature, and I want to make it work. >> Here is the real-world use case: When I yank I'm willing to wait for 2 >> or 10 seconds for the paste to complete, since the paste is what I >> actually want. But when I kill-new I want to wait less time, because >> the save-interprogram-paste-before-kill behavior is just a nice-to-have, >> which I want to happen if it's convenient and fast, not the actual thing >> I want to do. > > Have you actually tried setting just `x-selection-timeout' and found it > unsatisfactory? Yes. x-selection-timeout is configured to 5 seconds for every user at my site. They still find it unexpected and complain when killing takes that long. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 05 20:12:55 2023 Received: (at 64423) by debbugs.gnu.org; 6 Jul 2023 00:12:55 +0000 Received: from localhost ([127.0.0.1]:39134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHCcB-00018y-8O for submit@debbugs.gnu.org; Wed, 05 Jul 2023 20:12:55 -0400 Received: from sonic310-25.consmr.mail.ne1.yahoo.com ([66.163.186.206]:40246) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHCc8-00018k-HD for 64423@debbugs.gnu.org; Wed, 05 Jul 2023 20:12:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688602365; bh=eyp9TS1g/M1ilVjqwjiXYwxL3BHHeukGPYoZQdOA/pk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=r60cIS3BKct6a3rGKRlUT/OD6+12SMA0Um0Ua4jTMY0pRijyQwy1fu5j8fvwNdnUL1dCQypKEyy6Opi9RUBVKZKlG+VjdoNM2OckkPs7AB+li6g30FB3M3LZ3pUL2SsTSuBEmkSG5UV7P4k8gXMGrQYB7VDw/904yFTufHB2PcLALBAEr5MZo5juXTg9dNCnNtwfRVsos4+yvK3U9QvAVqAZAb/4QmD9nYovPd22pmYr+7+4gMjNdZDuEFAcJfOCXtPNZqWGmxwJOO56fttuhM6pmwhTKOcKVQRnwWsmGlLKDB+a28MyEbHPyMlOSEokRRqciWYIo5l/tMsvk1V77g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688602365; bh=J+QaNhgY0Pj1cINeOlkChEy40REnt0nAckr4pDjlv6a=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=ZEB3b+l/jNCk53gEJwZHsmNqQ8qz2JQugs5jIIP+7lAXQq14Nq74P/ZbmRzDvIHqIKfr1Ut1mcFvPYy7sEVDgvzQSkGOMR0vCFLPR/TZYQDTEdP2nSmiUQ6/w0K2MLvGu4J2IKwBI7MmxSlvQ6QV3XRAIfGmzzkdj2bEbGSC488kaI/b0WQwugyJervUCIUTxUwwl5CnBLlFdWxmcq9wyZNwjkd6JsHvTsZds1bil8Aj0pEFzOPTKLsbGYiLYBdU9ihrcVLNpTOXKPtY+fU3pTZZsnRH+NYErI97jAe8PhQQHFxlj1T1Zu/1yOUkDg6b+ofDtrSp6O64WuFnwCTFZg== X-YMail-OSG: RmPK9awVM1m7V9SplORv0SUA5lmg7cyMD.9J0aj398.ntZsh4v2F8UWNPWLDe2w JkqfzIf6HSnAReLDYZsswHOXs2JtsPYeMi4btmn7gMX6B2j5._kcAANxnOx_MHsiFK6MB_NhBsFu OGyk4K7VpxZxKsz5GA74akepyrK93hKrglVDE.u.Q2WHf5BAalP1zH5AYY58RvoJrxaFlsalATsr tpuQqO4fIwxv.yMIsbcI8hxp8bOpVPn8gwtLF8oXA9u0UPce3j8A5QXkyKhjs2AvGZXQCONZ2RSW ec8ARhoVv4VZZmfVnhAv5J.QnbgrlgFjkygdkD28AiP9HugzPH35.jEkYKdOj_fh2bRNhQLDFKtM u0duFPUfUu_H08teOB5JKANpPNZVBP4C.93L7IkbWVu2Qtv6wKimdpjZYmZVzKLoljkCymayAPhY qHApeTTLiTmpTD4WEqxA3IIlDC9ckgyTZz33GAOlHreXYB31o4MM0XIPeuvPPhXQrJL8pXEMaesS ilYOVqKaR3KAPRqyheSZYS.bBPf6qwrvamiNjcvsQC3_8J5Fv3H1hjMwalBAWyx6esNzAvdG6osn 2rLQoG68cKYRYhDwYhr8nyjVwl4TiN7kDsV9XlSuEH4UyOGOU_fr1h.iJl15rW4HBwvPmo_jYiSS Nv1JY3eiaH6.zFsjl84IZsdnB4V.JWwRV1.c4zLnsC7ua8udSQTICQgBXA71.c3KQ.M77OOV0GMh DkyWwjhocEzLgmT4oTZR2J3APjYC0KKgVPOAX6HOpGvzIHazBVhMFqund9Rj3VAxPByfi6FCSpHn 1jbYVrvBjSG8VKtnftfHBEa2ZD1HbxQkosx7hj3FOlJOGa67fVtAvNXUlZOaCsRo7Mm9FOaHC3wK 1ThUBrop8nkqUKq9AD9ryqtbWMgVjqil9k8HSxDHrDlIDI6N5qf_q8NEzv7v_.ZdXOFXj.A0gust iSiaRvMPb6bg3Ei0yjh6GO3S.YJpm4Wwef57dIp82_t.MHAvHlqmWK09pUyyPk5_kx7_odHpyhUZ .pwn9AeBaHI7jMoKiuoGAfLfg.TGMNdKrekb8NoAL.mN8PQOX4z2KNmp0REIvHgby.aEJp.ohK.7 foUXJSjXctzK0YgDuphxvC7.oICVPJX9VCChP5P.XxqUlsuwyq7pFvtGUtZ82_dYC7f5Nm5JhN4Y dj6X_H58inMhSETsq.paXGk12jqHu2ucB.SWxqDEQnClLrboepc.uvvtvqphFfO2AWmf9TfP1zkf RxDbco1B4dJmwni2VGGNDdakoqCKsPcHtxd9zjCccWIhV2PFSXQzllcfXwAsSGAMSPp0W0ERgr97 j_D7eqvN7A6zYf4Ithd.0IB.UGdoB2yL4ugZWzorRzYxE90B_NlWbxMvl9_1HzZFJGvXoaJ2WSgi LGOPd14g8aqUvQ81ThjhIsFKsLMLfvAs0aDO0Bvhx2J5tVNaf5aKmd_20sqipjhLxSDtZYH562b7 SVLEzsoXMdKzXC9pcFA0Jh09P53JvoRq6KrJlp2m5k3YMUR49cNFHVQdd6lBOuOUR0ddgulqrNt3 hVjR.QleASN5urtnpG5pWy5uuoXwCESiifh8_DWxabt0Af_61S64kDvpnd8n6T4wofyY_gCyzpDJ QfUkw6ouHsN0ZpDFRyzENZ5QH_ltN6G7v4TUjYHNhN_oWlleiCfmZogr2brETg_UHGF3t6Mdckl9 CufkC8t8JB7WhG34Ug8CKL1vySlMc7smEF_tr5Hl4A2bn1Oklqzn6IFQa9ZDRK.MBzqJrdUlqDAf KHi63ZSSBGqyHxbf_qLqh1YovL4YHJ0f9IiIwOfLZ8_.SkL7KA5eG9wE0eYPBaoLXdh78ZusFJVS OOWyGY7EZ0oQ0xX1ISmc7K3caoaS1vxSb5bfN8zdFVKguTrFWi.ZppYOLtE0sHQpKcSsmzoWH6rK j6XLSbXj0YhuVgBrkzAv7ek8Q5sDawSHhJ0H.AscStHip0Xf_y_MBUBVTPlHrWcJIb_V4GUNVeiF _MlRPgFQ5hwm4mRkvCNBq99W8dwUEvL7TpDdwwJbBOlBjM516LFjd2ayG6yqEpx1NWWgr0DDUbGZ pERsRQ3o_lZIKBgiXiUdch3MHMyha2h6iA3Y3_onrPTQdKs_ZNE.jXFHcXNjD3vs3hVsCs9OjK3J qG7q6yZZbxnF28tHC248A4nxTRWcg7bqmbPnSgen_C06uiNXK8VxJgJl.0JMpErXS7Q7fhVXkpAe 3xTkBevavSDa_GqkxaTaBQvlCKQbwEQHM0ZPCIj.TvQKgt.aPVS0CDGjllw-- X-Sonic-MF: X-Sonic-ID: 39d0f471-e498-4f1e-ae01-1aa5eada8ed9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Jul 2023 00:12:45 +0000 Received: by hermes--production-sg3-67fd64777-t6vwt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID de21ccf6abd79d2e04f2c2ffed3da490; Thu, 06 Jul 2023 00:12:39 +0000 (UTC) From: Po Lu To: Spencer Baugh Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: (Spencer Baugh's message of "Wed, 05 Jul 2023 09:59:53 -0400") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <871qhnqkfg.fsf@yahoo.com> Date: Thu, 06 Jul 2023 08:12:34 +0800 Message-ID: <87ttuhnbil.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1753 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > The insignificant problem is Emacs potentially getting the wrong > selection if we interrupt an incremental selection transfer? Yes, when the user does so deliberately. > I'm confused, it seems like that contradicts what you said earlier. > > If interrupting an incremental selection transfer is an insignificant > problem, then there should be no obstacle to automatically interrupting > the incremental selection transfer if it's too large. Interrupting incremental selection transfer _automatically_ is a significant problem, because Emacs cannot judge if the selection owner is functioning normally. If the user quits, he has determined that it is not, so it is acceptable for Emacs to terminate the transfer there and then without considering the consequences to the selection owner and future selection transfers. > OK, so we are doing at least as good as other toolkits when it comes to > retrieving the selection. But at my site the UX is still worse than > other applications because save-interprogram-paste-before-kill makes > taking ownership of the selection block, while for other applications it > does not. And save-interprogram-paste-before-kill is a useful feature, > and I want to make it work. Other programs do not have a kill ring at all. > Yes. x-selection-timeout is configured to 5 seconds for every user at > my site. They still find it unexpected and complain when killing takes > that long. But do they complain about inserting the contents of the selection also taking too long? Or when a program other than Emacs blocks for more than 5 seconds upon Button2 or Ctrl+V? Anyway, this points to a problem with an X client at your site and not a problem with Emacs. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 05 20:50:42 2023 Received: (at 64423) by debbugs.gnu.org; 6 Jul 2023 00:50:42 +0000 Received: from localhost ([127.0.0.1]:39153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHDCj-00026w-Nm for submit@debbugs.gnu.org; Wed, 05 Jul 2023 20:50:42 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58635) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHDCh-00026j-QZ for 64423@debbugs.gnu.org; Wed, 05 Jul 2023 20:50:40 -0400 From: Spencer Baugh To: Po Lu Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87ttuhnbil.fsf@yahoo.com> (Po Lu's message of "Thu, 06 Jul 2023 08:12:34 +0800") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <871qhnqkfg.fsf@yahoo.com> <87ttuhnbil.fsf@yahoo.com> Date: Wed, 05 Jul 2023 20:50:34 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Po Lu writes: > Spencer Baugh writes: > >> The insignificant problem is Emacs potentially getting the wrong >> selection if we interrupt an incremental selection transfer? > > Yes, when the user does so deliberately. > >> I'm confused, it seems like that contradicts what you said earlier. >> >> If interrupting an incremental selection transfer is an insignificant >> problem, then there should be no obstacle to automatically interrupting >> the incremental selection transfer if it's too large. > > Interrupting incremental selection transfer _automatically_ is a > significant problem, because Emacs cannot judge if the selection owner > is functioning normally. If the user quits, he has determined that it > is not, so it is acceptable for Emacs to terminate the transfer there > and then without considering the consequences to the selection owner and > future selection transfers. And yet, we do this today: that's what x-selection-timeout does. Should we remove that functionality? I assume we should not remove that functionality. So if automatically interrupting a selection transfer if the owner takes too long is fine, what's the issue with interrupting it if the owner sends too much data? Both situations are usually the result of buggy X clients, both situations would break Emacs if not handled, both situations are standard considerations for robustness in any network protocol. >> OK, so we are doing at least as good as other toolkits when it comes to >> retrieving the selection. But at my site the UX is still worse than >> other applications because save-interprogram-paste-before-kill makes >> taking ownership of the selection block, while for other applications it >> does not. And save-interprogram-paste-before-kill is a useful feature, >> and I want to make it work. > > Other programs do not have a kill ring at all. Yes. And Emacs does, so it needs to do more work than other applications to make to work correctly. >> Yes. x-selection-timeout is configured to 5 seconds for every user at >> my site. They still find it unexpected and complain when killing takes >> that long. > > But do they complain about inserting the contents of the selection > also taking too long? Or when a program other than Emacs blocks for > more than 5 seconds upon Button2 or Ctrl+V? No, because then they are performing an operation which it makes sense might block: pasting data copied from another application. In that situation, they are fine with it. > Anyway, this points to a problem with an X client at your site and not a > problem with Emacs. No, there is no problem with other X clients. It is simply that users expect delays when yanking and don't expect delays when killing. So, Emacs should be able to configure a different x-selection-timeout when running the save-interprogram-paste-before-kill logic, to reflect the fact that users have these different expectations for yanking and killing. I don't see why this is objectionable. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 05 21:59:32 2023 Received: (at 64423) by debbugs.gnu.org; 6 Jul 2023 01:59:32 +0000 Received: from localhost ([127.0.0.1]:39178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHEHM-0003lr-8Q for submit@debbugs.gnu.org; Wed, 05 Jul 2023 21:59:32 -0400 Received: from sonic317-33.consmr.mail.ne1.yahoo.com ([66.163.184.44]:37622) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHEHI-0003lX-PB for 64423@debbugs.gnu.org; Wed, 05 Jul 2023 21:59:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688608762; bh=HYbzHBwnikTVCbmKFuqKSAbKphCYjnV0ZAoxqT8XbpI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=t/V4wT35I/dqW3gu08W16ioui55UdO7lqj2Hz20e4x/oepcZf5ZYHzeXVLJxja2EU6BrL2cFqEU3bFZ+LNFQQL2+eCZnnG2TLIqoQ3CckEcCgWuN7cuGPoJM7AwZrnGxH8mckqN7rVjaa7tRU+o4Q/yh9JxkRs7x3b80wIy8LLCDF10e2AjBX8aF7e9JLQhoiHwJ7jB0jxq9OsySLtueJyvHIrlbkTQOo3lNMg67VdftubIuGwViPgjTTfTg8JelkuDUEV44HkIOlRe8RVdM169ZVXdCt8w+UDmFLiw9ry5GaYTMoVs6m0Or2gsBfO0VuZmZl/tZc1Vw+/RgQwIUrQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688608762; bh=I0T52kp8r413veRGdI+opwUsMwFwaQ1sFd3jfIffJO4=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=OFu7n19qd9N6b7v1rtHnYQo1bzRh6H+4DniwdShYQbA83K6LU/BhX6tlJdST7uZnH0q2w7ZHnSTCMvzYA3THQMpJeh8g1QapsuNnwuQqaN5/IRmL5030/V92kPf3QuH8H+QhT3nEjG/8GDRJ1avTUPX/VJ7KeRN259l+ZvmXhVEaJqIlaoq5I6WXZXk6kGGLsJHQDY7PVKjYqXzxWUg8ilzyTbhYIBFUZO/DjY2TFpLk2aWbmdFinnug/E3fYU7oQPVdsiPGqZKpZEACXoqp7yN5GCjq4Lh/rfG+2o/wd/kOCIH1h6QLhH6ET7vmtCE+rfQ86T+4ydxFdZWYXcjefg== X-YMail-OSG: cwO7AXkVM1noCtGRyjreLXCWAgwPGAHYNt5L9.EgDv7AQAXvzvhBbwHjfElaAFl 6iRIywjxLxB4BNVRGBtVTs9sQcejpgtxHjdz1aa0IYTMSFWf8QedID3cuwVrS0J24R0Gk2yuy.2g _O03I9TBh08oLA3.GYoIKdk5fmAaHMQP06mJIlNWqr0VGxepMDol.6aUXZVUowWOQ12anAJJcAmv RszNt4na.Uq.SBSeEqYu8_a_Ranma7rTvTRXmMBT8aSzewxL7tyKIjKalsyPPQI6_0_og520W1IL c6McjB8G0IzmCL_lPTAPhFJ3tdMMCFBc2PGBJjiVnoaANHGm.6cdmpf7Mm06fN9v0OZI90gnNqaD YRX9j8TFnW2L5IeVmkzyF2ZfGAzh5mvCvb8dTh2En7rwsgxJL5JBjkmWrk3_aPsCpE.1WBQEXsQ6 ZhMP0n_KjnBwAq5bb3bgxvnuA6zhzyzHzYgdtmabaKBYZ9te5h09MpgJa8e2.uJHajAPKLKnj1bd OvcCmF03cEq.FYfA79lXxffW2OE_PFqTZTTBmuK0OdbxXIcA_h7ijuV8Fs5UCi_4.9hZxfJhruzb snfr7.hfMThhiKBU3LsFqKLCgGwyiiQypExeTRAgCzdmKcLrlWZ_uDa8IvlKIrWn9O7k3HSpGBNN C4k7h2dGje8HPPJClRip_IJkOODyiOVh8Agfv5wcO3LtnezktF2Yh58HPp8ygEhzN7hhL0KaHw3F Du8Edq_nnw7Mg3wegTYBRHnfo9TfIm41hKu5Lp9kP84Z8.Tp_jhp_gQ46lI6zPza2hO8AMJrvbrV GpXVoMu70dHc9f1n0Q78q4yk7B7f3bcWknFoWU37TxUp1_mIk94RphDRFEQZfHx8hjjU0gJcO5IS iF773aUHRBDGc6CR3gQknVWwgdsLacxqRvjBiFQwZbClcFegq4IHiO6VEruXFAVFwgltaMuSl.0P vm99QcBOsUYOGuJskJDnQblaFP5J6mNPR8gjzHkC99WBiwGu3bHHwgOMRCe6M8QaHcnh7yKsv22D WRNmdc8N6KmBCrgYZQ2IQ718QpMNpDNvxg1ryc0LvNoe_a0QJDH0UPLfBvLvHpHhTh7kaIJSIL3m VwF02svpAgBHysGIhnpiTWNQ27GqYLF0ra9W91K6zczmwkhNH3taV4WtwHFdLe1R8NX50dyRkahx 99bmxY1unpBa4mslV_LGlel5HUaxq9piC74L3.cL7EoBvR8X4Ec8MMBe._YMpGpJDTClFpohxj6V .7.SFvHCHDboHelqMddRF4uP.XqewI98WgzcujLy7t0xWg5wi_iqdZELmroADeRA7rutkgsZoKKn izjc9Xm9C0lZyVh1.yTTmW.4td0deoBlzXAKTZavayorU8X5F23.tXvLdvKJkdzE80GN92zPBL.x RV4nqj8Sfa4TVKB4nKERNcaRa7HEcrX5hQw1ldlFzHjsyaL1.Jaca0N.mU2vYsiKvYZ_knx4wJoQ nzZ.uFy8N0u1FyGCZCIwoMb32i25z4x.xRmUKMwonxcsuDf4jKm6.gfGexLkQBzwwiyuAWRFIQ_a u8AQ0mBRRav_EF5Zk3mLq5b8HBaedlKl4xBffrnblIvLWxUXdl3mCkWGcrCvsWOf0l_E5RoZpo65 hNixzS20klpWo7tO2SsCdiseA5yaZuLTAZm89SIUSz3f3mjxnouLmB3f86oXo3uHTKN8B2XKVubl .qUTZtLnkxmKqMEvrixiEAjAzlvgHFQYcf4CwAtAe6vNQRuE7IJdL9bpQwd9SRfS6QacD6vOXPKp xBVa5kavuCAzph3uRrFzQriUhe1z.MNSuxEIxNnzFj_TMLZUExtblyJ7jFn08pkILv5KJtQFlrp_ eZukTyOpiooxW.mtX5eqRUPuYgYwBStiAWLUn4Z5rdOAJFYbwbkmdEjdQlv1kZEGMlHRtO1DJy2B 4DtBvhuXrttdvkHC01GWe5sS0cqHsCi2wOzpYne4l2UqaSXSEwbwhq6jeq65frHsaZOKx5hJaaSV l_8n1oP4RaX7U8xCg458o7ucPlOte9YVNF5jY5RzEzNVvwlqHOIGl.3_UGgeEMDMjcw_iZ9KrXSm _HIDwn1mjJWp3EMkY_cffPMrj.kLgnbPfUI9E2RB6lH5wCp7_ol4Yh3f3bB.8JZqPCMMDNBPlk4a Pcig.66M59S9LDc.R4rgJ6FtwahC7_LKBarF701mW_93Eu.DfrfDfFnKI16.67XjbJU0XAWNrav5 Uo3w0836FiXQmCnhmjI2DgrKQgzSI71hbzcftaakdKnHXNeCvHW5ReUmpk11cvlXK X-Sonic-MF: X-Sonic-ID: a8f8130c-57b4-4372-9458-3996ea7fa920 Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Thu, 6 Jul 2023 01:59:22 +0000 Received: by hermes--production-sg3-67fd64777-srcqr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bef17c55a572876bc8e00eeace01eab6; Thu, 06 Jul 2023 01:59:19 +0000 (UTC) From: Po Lu To: Spencer Baugh Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: (Spencer Baugh's message of "Wed, 05 Jul 2023 20:50:34 -0400") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87h6qjreyw.fsf@yahoo.com> <87jzvfohtg.fsf@catern.com> <871qhnqkfg.fsf@yahoo.com> <87ttuhnbil.fsf@yahoo.com> Date: Thu, 06 Jul 2023 09:59:14 +0800 Message-ID: <878rbtn6kt.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1544 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Spencer Baugh writes: > And yet, we do this today: that's what x-selection-timeout does. Should > we remove that functionality? [...] > I assume we should not remove that functionality. So if automatically > interrupting a selection transfer if the owner takes too long is fine, > what's the issue with interrupting it if the owner sends too much data? Because sending a lot of data is *NOT* a bug in the selection owner. Delaying subsequent user activity for a significant amount of time is. > Both situations are usually the result of buggy X clients, both > situations would break Emacs if not handled, both situations are > standard considerations for robustness in any network protocol. Blocking user interaction while quitting remains possible is not ``broken'' in my book. > No, because then they are performing an operation which it makes sense > might block: pasting data copied from another application. In that > situation, they are fine with it. [...] > No, there is no problem with other X clients. It is simply that users > expect delays when yanking and don't expect delays when killing. > > So, Emacs should be able to configure a different x-selection-timeout > when running the save-interprogram-paste-before-kill logic, to reflect > the fact that users have these different expectations for yanking and > killing. I don't see why this is objectionable. Taking more than five seconds to yank points to a bug in whichever client is owning the clipboard selection at the time of the yank. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 08 12:39:09 2023 Received: (at 64423) by debbugs.gnu.org; 8 Jul 2023 16:39:09 +0000 Received: from localhost ([127.0.0.1]:45110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIAxg-0005SE-Mo for submit@debbugs.gnu.org; Sat, 08 Jul 2023 12:39:09 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:19652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIAxe-0005Re-J7 for 64423@debbugs.gnu.org; Sat, 08 Jul 2023 12:39:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: cc:content-type:from:subject:to; s=s1; bh=KYoMkT002yoXT7XiIe0vZ0Edrc0lEkaSYVTzcfUapTQ=; b=iodZtyXHCJbThusnluWn9Z/wYBc6U22LZbFV9+8p2xAJB3EVZgJXiYMFOb+3A0l06bqB F1qrKxgEUZT23uv5O7rTo+WHNSygXkN2XaKNHl9ADBlpkHuJeNiCy51QHem6qeHP6/1M7u EowiIK8mESPA3+9lrpGWHvzg3bwLptkb7CdQ1mT2NbI3uTUeINFj6mJfQfLMo3I7r8Qss3 n2dseEpMSlzW9cjiC9pRaQbbbN9nidO9c+Kmx58/DZbucUaLYOBFW7X3HTBa9BhONGDIHz v1Fxi7XWicR0MOOIh2OM0Xdy8QUYX1crtR2mANnC1tomkoqWptaNjymBVKvDheKw== Received: by filterdrecv-84b96456cb-hrvlt with SMTP id filterdrecv-84b96456cb-hrvlt-1-64A99124-12 2023-07-08 16:39:00.448431669 +0000 UTC m=+5072425.444531642 Received: from earth.catern.com (unknown) by geopod-ismtpd-15 (SG) with ESMTP id x7GJlNhLSMSfNTUkrbydUw Sat, 08 Jul 2023 16:39:00.207 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=yahoo.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id A335D6004F; Sat, 8 Jul 2023 12:38:59 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87mt0bq4py.fsf@catern.com> (sbaugh@catern.com's message of "Tue, 04 Jul 2023 11:46:34 +0000 (UTC)") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> Date: Sat, 08 Jul 2023 16:39:00 +0000 (UTC) Message-ID: <87mt06mk7w.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbLp8QcpjKixcTZS0hXF2c?= =?us-ascii?Q?cz2lQLK5ME56JYKgHNzKGtPtrrzQ+ptJrW2NY12?= =?us-ascii?Q?IBdW1Z1cYtLkqJUyTh7kSAxz6Q83AL06COyS5fp?= =?us-ascii?Q?ALSFlbirxVwWBnSl+MKe7Pjtw305FyfnJ4lP7rC?= =?us-ascii?Q?L6Uhe0Gi+0ZIrhub=2F0fC1QMRRU0=2FwdCiK1A=3D=3D?= To: Po Lu X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: sbaugh@catern.com writes: > Po Lu writes: >> sbaugh@catern.com writes: >> >>> Po Lu writes: >>> >>>> Spencer Baugh writes: >>>> >>>>> [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 RCVD_IN_MSPIKE_H4 RBL: Very Good reputation (+4) [149.72.123.24 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit sbaugh@catern.com writes: > Po Lu writes: >> sbaugh@catern.com writes: >> >>> Po Lu writes: >>> >>>> Spencer Baugh writes: >>>> >>>>> When you do that, you interrupt the operation which is trying to add a >>>>> new kill. If you interrupt it and try again, you'll just get the same >>>>> long delay again. There's no way to mitigate this from within Emacs, >>>>> other than by turning off save-interprogram-paste-before-kill. >>>> >>>> Then I guess the solution is to temporarily disable >>>> `save-interprogram-paste-before-kill' if a quit arrives while it is >>>> reading selection data. >>> >>> That would be a decent solution. Although I'm not sure how we'd >>> implement it. We want to, somehow, know that after a selection-transfer >>> has been aborted, we should not try to transfer that selection again. >>> Is that something we can check? Whether the selection has changed, >>> without transferring it? >> >> Emacs will probably assert ownership of the selection after the kill >> takes place, anyway, so there is no need. > > Good point! So maybe if a quit arrives while we're reading the > selection in kill-new, we should immediately take ownership of the > selection. With an condition-case, perhaps. > > Or... just ignore the quit. If we're reading the selection in kill-new > and there's a quit, just proceed to doing the kill. Here is an implementation of that. I think this is the right strategy and I'm glad we discussed this, I think this will behave better for users than my original suggestion, and this way doesn't require any configuration. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Ignore-quit-while-getting-interprogram-paste-in-kill.patch >From b7b0feb879994696bdd6f6f4cc982779b1ff5b45 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sat, 8 Jul 2023 12:36:22 -0400 Subject: [PATCH] Ignore quit while getting interprogram paste in kill-new On X, if the current selection owner is not responding to selection requests, the user may want to take ownership of the selection. The obvious way to do this is to kill some text (which a user might also be doing just as part of normal editing at the time the selection owner becomes nonresponsive). However, if save-interprogram-paste-before-kill is non-nil, then killing text will hang until the user quits, and this quit will abort the entire kill-new, preventing the user from taking ownership of the selection. Now instead if the user quits while we are attempting to retrieve the selection from hanging owner, we will proceed to take ownership of the selection as normal, resolving the problem. (One example of a selction owner that might not be responding to selection requests is another instance of Emacs itself; while Emacs is blocked in call-process or Lisp execution, it currently does not respond to selection requests.) * lisp/simple.el (kill-new): Ignore quit while getting interprogram paste (bug#64423) --- lisp/simple.el | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lisp/simple.el b/lisp/simple.el index 26944f1f72d..95d00cc506b 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5618,8 +5618,10 @@ kill-new (if (fboundp 'menu-bar-update-yank-menu) (menu-bar-update-yank-menu string (and replace (car kill-ring))))) (when save-interprogram-paste-before-kill - (let ((interprogram-paste (and interprogram-paste-function - (funcall interprogram-paste-function)))) + (let ((interprogram-paste + (ignore-error 'quit + (and interprogram-paste-function + (funcall interprogram-paste-function))))) (when interprogram-paste (setq interprogram-paste (if (listp interprogram-paste) -- 2.41.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 08 12:48:33 2023 Received: (at 64423) by debbugs.gnu.org; 8 Jul 2023 16:48:33 +0000 Received: from localhost ([127.0.0.1]:45116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIB6m-0005qK-Vo for submit@debbugs.gnu.org; Sat, 08 Jul 2023 12:48:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIB6k-0005pT-UY for 64423@debbugs.gnu.org; Sat, 08 Jul 2023 12:48:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIB6f-0003wE-5H; Sat, 08 Jul 2023 12:48:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dx+9/b66434p4jp2SXpQLbnaf5azuFLXKv6+sU0R1LQ=; b=Igd5IZyaISTQ t27uUvWHmXT9riZ8/3wSrxdGqvkqDvhwQsGIIZoV233bwkawofgAVQuCT9Y2gIXCRzMDUpeyTsusR rhOX1cCPWXG5RF9aUAOUAaSwxL+VD0um6sj/KFAfWRtaWSR4j30XK0z3BabkE3y2tbmlYqH54xEBE 9la03upGPB9A9+sFV76wXVUIa99ouQ2dm/4PEkv8P8Qe+4IBtHst2XtOeBS1iLKkFvMTRbFn2PuAF Z4XqTpMlXIhOiH0WDNo2WXygboZaVMrG6ofOZPcGjPTnOF3QTwRRPW31/xtHsmWa5TB4jkwCvK7wt Y+tquclMnpd9Y1a+PnSVVw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIB6e-0000oF-Ik; Sat, 08 Jul 2023 12:48:24 -0400 Date: Sat, 08 Jul 2023 19:48:29 +0300 Message-Id: <831qhicpsy.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87mt06mk7w.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Spencer Baugh , 64423@debbugs.gnu.org > From: sbaugh@catern.com > Date: Sat, 08 Jul 2023 16:39:00 +0000 (UTC) > > diff --git a/lisp/simple.el b/lisp/simple.el > index 26944f1f72d..95d00cc506b 100644 > --- a/lisp/simple.el > +++ b/lisp/simple.el > @@ -5618,8 +5618,10 @@ kill-new > (if (fboundp 'menu-bar-update-yank-menu) > (menu-bar-update-yank-menu string (and replace (car kill-ring))))) > (when save-interprogram-paste-before-kill > - (let ((interprogram-paste (and interprogram-paste-function > - (funcall interprogram-paste-function)))) > + (let ((interprogram-paste > + (ignore-error 'quit > + (and interprogram-paste-function > + (funcall interprogram-paste-function))))) > (when interprogram-paste > (setq interprogram-paste > (if (listp interprogram-paste) Are you sure this is TRT for all the implementations of GUI selections? AFAIU, the discussion was only about X. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 08 13:07:45 2023 Received: (at 64423) by debbugs.gnu.org; 8 Jul 2023 17:07:45 +0000 Received: from localhost ([127.0.0.1]:45128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIBPN-0006WP-ET for submit@debbugs.gnu.org; Sat, 08 Jul 2023 13:07:45 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:42757) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIBPL-0006W6-9d for 64423@debbugs.gnu.org; Sat, 08 Jul 2023 13:07:44 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <831qhicpsy.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 08 Jul 2023 19:48:29 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> Date: Sat, 08 Jul 2023 13:07:37 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Cc: Spencer Baugh , 64423@debbugs.gnu.org >> From: sbaugh@catern.com >> Date: Sat, 08 Jul 2023 16:39:00 +0000 (UTC) >> >> diff --git a/lisp/simple.el b/lisp/simple.el >> index 26944f1f72d..95d00cc506b 100644 >> --- a/lisp/simple.el >> +++ b/lisp/simple.el >> @@ -5618,8 +5618,10 @@ kill-new >> (if (fboundp 'menu-bar-update-yank-menu) >> (menu-bar-update-yank-menu string (and replace (car kill-ring))))) >> (when save-interprogram-paste-before-kill >> - (let ((interprogram-paste (and interprogram-paste-function >> - (funcall interprogram-paste-function)))) >> + (let ((interprogram-paste >> + (ignore-error 'quit >> + (and interprogram-paste-function >> + (funcall interprogram-paste-function))))) >> (when interprogram-paste >> (setq interprogram-paste >> (if (listp interprogram-paste) > > Are you sure this is TRT for all the implementations of GUI > selections? AFAIU, the discussion was only about X. Independent of that discussion, I think this change should be harmless. The worst thing that this change can cause is that a call to kill-new can complete successfully when it otherwise would have failed. That's probably always good, especially because kill-new is usually preceeded by deleting text, which might be unrecoverable in buffers without undo. But, also, I believe the discussion makes sense for platforms besides X: if there's a bug in the current owner of the clipboard, then taking ownership of the clipboard in Emacs will let us avoid that bug. And this change to ignore quits will allow the user to take ownership of the selection in that way, whereas they previously would not be able to (without manually writing some Lisp anyway). From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 08 13:49:17 2023 Received: (at 64423) by debbugs.gnu.org; 8 Jul 2023 17:49:17 +0000 Received: from localhost ([127.0.0.1]:45143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIC3Y-0008BP-Ur for submit@debbugs.gnu.org; Sat, 08 Jul 2023 13:49:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIC3W-0008B4-N2 for 64423@debbugs.gnu.org; Sat, 08 Jul 2023 13:49:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIC3Q-0006qc-LD; Sat, 08 Jul 2023 13:49:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jyMqS8KysHGyimxkWIArVtjABlMi2CIJHN/qj2qn6B0=; b=eN3WZbwFzXWo xoWBAfjJILopky1lJH9dTemGWfw8TwN3o4f5HnWkHdcqUoYlZOJEgBM3PejWsoE3Zx/za86Hxky0r JmYVOkYw+0aDvccCx15ZXLAVFO+laDFmC17RAy59oGNbDL0KldNean622jwii4Ko45Tx8uKPMWFXf +DXqA1GCFnCSNT3kUa2l/WYSOwNb/1Y6rIOTOHPoGQSG8YEPP9e7UJcEZ9oU1sNissdBStzBFsqFS 7XGsksPuopq36NCzS/LD/S/N5/UCD5Jc02nFqC9aVRaNb7Je3AOLLnb4DQH6zeQH3g35gg+Le5Y/Y RrTKcNfzo1eXKZgFxGng4Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIC3Q-0002IX-4z; Sat, 08 Jul 2023 13:49:08 -0400 Date: Sat, 08 Jul 2023 20:49:13 +0300 Message-Id: <83zg46b8fa.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sat, 08 Jul 2023 13:07:37 -0400) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@catern.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: sbaugh@catern.com, luangruo@yahoo.com, 64423@debbugs.gnu.org > Date: Sat, 08 Jul 2023 13:07:37 -0400 > > Eli Zaretskii writes: > >> Cc: Spencer Baugh , 64423@debbugs.gnu.org > >> From: sbaugh@catern.com > >> Date: Sat, 08 Jul 2023 16:39:00 +0000 (UTC) > >> > >> diff --git a/lisp/simple.el b/lisp/simple.el > >> index 26944f1f72d..95d00cc506b 100644 > >> --- a/lisp/simple.el > >> +++ b/lisp/simple.el > >> @@ -5618,8 +5618,10 @@ kill-new > >> (if (fboundp 'menu-bar-update-yank-menu) > >> (menu-bar-update-yank-menu string (and replace (car kill-ring))))) > >> (when save-interprogram-paste-before-kill > >> - (let ((interprogram-paste (and interprogram-paste-function > >> - (funcall interprogram-paste-function)))) > >> + (let ((interprogram-paste > >> + (ignore-error 'quit > >> + (and interprogram-paste-function > >> + (funcall interprogram-paste-function))))) > >> (when interprogram-paste > >> (setq interprogram-paste > >> (if (listp interprogram-paste) > > > > Are you sure this is TRT for all the implementations of GUI > > selections? AFAIU, the discussion was only about X. > > Independent of that discussion, I think this change should be harmless. How do you know that? The prudent thing in Emacs is to "do no harm", i.e. try hard not to affect any code that is unrelated to the problem. Assuming that a change is harmless is a mother of all bugs. > The worst thing that this change can cause is that a call to kill-new > can complete successfully when it otherwise would have failed. No, I think you can also do the reverse. And anyway, this kind of "reasoning" is what gets us in trouble time and again. Why risk all those potential problems, where the original issue doesn't exist in the first place? > But, also, I believe the discussion makes sense for platforms besides X: > if there's a bug in the current owner of the clipboard, then taking > ownership of the clipboard in Emacs will let us avoid that bug. And > this change to ignore quits will allow the user to take ownership of the > selection in that way, whereas they previously would not be able to > (without manually writing some Lisp anyway). You do realize that some window systems Emacs support have no notion of "clipboard ownership" or "selection ownership" whatsoever? So please modify the patch to affect only X, TIA. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 08 14:06:42 2023 Received: (at 64423) by debbugs.gnu.org; 8 Jul 2023 18:06:43 +0000 Received: from localhost ([127.0.0.1]:45167 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qICKQ-0000U3-FC for submit@debbugs.gnu.org; Sat, 08 Jul 2023 14:06:42 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:19528) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qICKN-0000Te-VV for 64423@debbugs.gnu.org; Sat, 08 Jul 2023 14:06:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=subject:in-reply-to:from:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=1BzrP3st5HZSphQmubYGLMOtPoTxD5DelZSb8kn4dqc=; b=qmRpva+j1ZBYIVqZg1KqNdE4UHG327U095lUPHorQniRhNSPS3zy7aC6iNy1SRxqPkhv VfD3J3QbEuIDnLYOi72Wv2Kpt/BtHYy4NMR7dsc0fnJ0t+Wic2ZiedybBTzV3VyNMQiL6H eVLzfUQmFea+d8C3ZqxQzeKtXLZXsxU8es5T7wRNgTJdDUfhPHAUi0k+pnxWej4JMBi7eo FTVeys+XMVMvMopSXic7X3kxIzkjbYgDm300A5rYijJciOdjws4SJJ2AHuhUhDnneveML6 6ZORtlHpFfi26R3h/vfxHCyYPbJzAn4HyRtBpUY51Y8GxFjlOmngpt4bdzmFy7ZA== Received: by filterdrecv-84b96456cb-bvsrh with SMTP id filterdrecv-84b96456cb-bvsrh-1-64A9A5A9-2F 2023-07-08 18:06:33.741519828 +0000 UTC m=+5077682.265146751 Received: from earth.catern.com (unknown) by geopod-ismtpd-23 (SG) with ESMTP id LRYkgUu6RcuzU_7X2wnu-w Sat, 08 Jul 2023 18:06:33.490 +0000 (UTC) Date: Sat, 08 Jul 2023 18:06:33 +0000 (UTC) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections Message-ID: <397b4b55-fe51-4413-8409-0c57aed2fe8a@email.android.com> X-Android-Message-ID: <397b4b55-fe51-4413-8409-0c57aed2fe8a@email.android.com> In-Reply-To: <83zg46b8fa.fsf@gnu.org> From: Spencer Baugh Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cO?= =?us-ascii?Q?rI4e0V+MFZgakz9Re5a6=2FCglbI1SPaPpDV4coyW?= =?us-ascii?Q?sp1x=2F05hnEfX5MdxKi01lmA=2FAHokxynkp1wXKzz?= =?us-ascii?Q?rB=2F8eRBeKhwlh4AD9xiioB4ShRMGgp644uyqV95?= =?us-ascii?Q?YVaaWx+lK32140qx1iiVrqdwxHJv4p8UgOPDpv0?= =?us-ascii?Q?uH07XVHO0nlFS5tDL8jWPHCTQ0pnVC0rnuPLgK?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: base64 X-Spam-Score: 3.0 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Jul 8, 2023 13:49, Eli Zaretskii wrote: > From: Spencer Baugh > Cc: sbaugh@catern.com, luangruo@yahoo.com, 64423@debbugs.gnu.org > Date: Sat, 08 Jul 2023 13:07:37 -0400 > > Eli Zaretskii writes: > >> C [...] Content analysis details: (3.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.154.232 listed in wl.mailspike.net] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 1.0 MALF_HTML_B64 Malformatted base64-encoded HTML content X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, Spencer Baugh , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Jul 8, 2023 13:49, Eli Zaretskii wrote: > From: Spencer Baugh > Cc: sbaugh@catern.com, luangruo@yahoo.com, 64423@debbugs.gnu.org > Date: Sat, 08 Jul 2023 13:07:37 -0400 > > Eli Zaretskii writes: > >> C [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.154.232 listed in wl.mailspike.net] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 1.0 MALF_HTML_B64 Malformatted base64-encoded HTML content -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager PGRpdiBkaXI9J2F1dG8nPjxkaXYgZGlyPSJhdXRvIj48ZGl2IGNsYXNzPSJlbGlkZWQtdGV4dCI+ T24gSnVsIDgsIDIwMjMgMTM6NDksIEVsaSBaYXJldHNraWkgJmx0O2VsaXpAZ251Lm9yZyZndDsg d3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj48YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjAg MCAwIDAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPjxw IGRpcj0ibHRyIj4mZ3Q7IEZyb206IFNwZW5jZXIgQmF1Z2ggJmx0O3NiYXVnaEBqYW5lc3RyZWV0 LmNvbSZndDsKPGJyPgomZ3Q7IENjOiBzYmF1Z2hAY2F0ZXJuLmNvbSwmbmJzcDsgbHVhbmdydW9A eWFob28uY29tLCZuYnNwOyA2NDQyM0BkZWJidWdzLmdudS5vcmcKPGJyPgomZ3Q7IERhdGU6IFNh dCwgMDggSnVsIDIwMjMgMTM6MDc6MzcgLTA0MDAKPGJyPgomZ3Q7IAo8YnI+CiZndDsgRWxpIFph cmV0c2tpaSAmbHQ7ZWxpekBnbnUub3JnJmd0OyB3cml0ZXM6Cjxicj4KJmd0OyAmZ3Q7Jmd0OyBD YzogU3BlbmNlciBCYXVnaCAmbHQ7c2JhdWdoQGphbmVzdHJlZXQuY29tJmd0OywgNjQ0MjNAZGVi YnVncy5nbnUub3JnCjxicj4KJmd0OyAmZ3Q7Jmd0OyBGcm9tOiBzYmF1Z2hAY2F0ZXJuLmNvbQo8 YnI+CiZndDsgJmd0OyZndDsgRGF0ZTogU2F0LCAwOCBKdWwgMjAyMyAxNjozOTowMCArMDAwMCAo VVRDKQo8YnI+CiZndDsgJmd0OyZndDsgCjxicj4KJmd0OyAmZ3Q7Jmd0OyBkaWZmIC0tZ2l0IGEv bGlzcC9zaW1wbGUuZWwgYi9saXNwL3NpbXBsZS5lbAo8YnI+CiZndDsgJmd0OyZndDsgaW5kZXgg MjY5NDRmMWY3MmQuLjk1ZDAwY2M1MDZiIDEwMDY0NAo8YnI+CiZndDsgJmd0OyZndDsgLS0tIGEv bGlzcC9zaW1wbGUuZWwKPGJyPgomZ3Q7ICZndDsmZ3Q7ICsrKyBiL2xpc3Avc2ltcGxlLmVsCjxi cj4KJmd0OyAmZ3Q7Jmd0OyBAQCAtNTYxOCw4ICs1NjE4LDEwIEBAIGtpbGwtbmV3Cjxicj4KJmd0 OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoaWYg KGZib3VuZHAgJ21lbnUtYmFyLXVwZGF0ZS15YW5rLW1lbnUpCjxicj4KJmd0OyAmZ3Q7Jmd0OyZu YnNwOyAJJm5ic3A7IChtZW51LWJhci11cGRhdGUteWFuay1tZW51IHN0cmluZyAoYW5kIHJlcGxh Y2UgKGNhciBraWxsLXJpbmcpKSkpKQo8YnI+CiZndDsgJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgKHdoZW4gc2F2ZS1pbnRlcnByb2dyYW0tcGFzdGUtYmVmb3JlLWtpbGwK PGJyPgomZ3Q7ICZndDsmZ3Q7IC0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKGxldCAo KGludGVycHJvZ3JhbS1wYXN0ZSAoYW5kIGludGVycHJvZ3JhbS1wYXN0ZS1mdW5jdGlvbgo8YnI+ CiZndDsgJmd0OyZndDsgLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAoZnVuY2FsbCBpbnRlcnByb2dyYW0tcGFzdGUtZnVuY3Rpb24pKSkpCjxicj4KJmd0OyAm Z3Q7Jmd0OyArJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChsZXQgKChpbnRlcnByb2dy YW0tcGFzdGUKPGJyPgomZ3Q7ICZndDsmZ3Q7ICsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKGlnbm9yZS1lcnJv ciAncXVpdAo8YnI+CiZndDsgJmd0OyZndDsgKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAo YW5kIGludGVycHJvZ3JhbS1wYXN0ZS1mdW5jdGlvbgo8YnI+CiZndDsgJmd0OyZndDsgKyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoZnVu Y2FsbCBpbnRlcnByb2dyYW0tcGFzdGUtZnVuY3Rpb24pKSkpKQo8YnI+CiZndDsgJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHdo ZW4gaW50ZXJwcm9ncmFtLXBhc3RlCjxicj4KJmd0OyAmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoc2V0cSBp bnRlcnByb2dyYW0tcGFzdGUKPGJyPgomZ3Q7ICZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChpZiAobGlzdHAgaW50ZXJwcm9ncmFtLXBhc3RlKQo8 YnI+CiZndDsgJmd0Owo8YnI+CiZndDsgJmd0OyBBcmUgeW91IHN1cmUgdGhpcyBpcyBUUlQgZm9y IGFsbCB0aGUgaW1wbGVtZW50YXRpb25zIG9mIEdVSQo8YnI+CiZndDsgJmd0OyBzZWxlY3Rpb25z PyZuYnNwOyBBRkFJVSwgdGhlIGRpc2N1c3Npb24gd2FzIG9ubHkgYWJvdXQgWC4KPGJyPgomZ3Q7 IAo8YnI+CiZndDsgSW5kZXBlbmRlbnQgb2YgdGhhdCBkaXNjdXNzaW9uLCBJIHRoaW5rIHRoaXMg Y2hhbmdlIHNob3VsZCBiZSBoYXJtbGVzcy4KPGJyPgoKPGJyPgpIb3cgZG8geW91IGtub3cgdGhh dD8mbmJzcDsgVGhlIHBydWRlbnQgdGhpbmcgaW4gRW1hY3MgaXMgdG8gImRvIG5vIGhhcm0iLAo8 YnI+CmkuZS4gdHJ5IGhhcmQgbm90IHRvIGFmZmVjdCBhbnkgY29kZSB0aGF0IGlzIHVucmVsYXRl ZCB0byB0aGUgcHJvYmxlbS4KPGJyPgpBc3N1bWluZyB0aGF0IGEgY2hhbmdlIGlzIGhhcm1sZXNz IGlzIGEgbW90aGVyIG9mIGFsbCBidWdzLgo8YnI+Cgo8YnI+CiZndDsgVGhlIHdvcnN0IHRoaW5n IHRoYXQgdGhpcyBjaGFuZ2UgY2FuIGNhdXNlIGlzIHRoYXQgYSBjYWxsIHRvIGtpbGwtbmV3Cjxi cj4KJmd0OyBjYW4gY29tcGxldGUgc3VjY2Vzc2Z1bGx5IHdoZW4gaXQgb3RoZXJ3aXNlIHdvdWxk IGhhdmUgZmFpbGVkLgo8YnI+Cgo8YnI+Ck5vLCBJIHRoaW5rIHlvdSBjYW4gYWxzbyBkbyB0aGUg cmV2ZXJzZS4mbmJzcDsgQW5kIGFueXdheSwgdGhpcyBraW5kIG9mCjxicj4KInJlYXNvbmluZyIg aXMgd2hhdCBnZXRzIHVzIGluIHRyb3VibGUgdGltZSBhbmQgYWdhaW4uJm5ic3A7IFdoeSByaXNr IGFsbAo8YnI+CnRob3NlIHBvdGVudGlhbCBwcm9ibGVtcywgd2hlcmUgdGhlIG9yaWdpbmFsIGlz c3VlIGRvZXNuJ3QgZXhpc3QgaW4KPGJyPgp0aGUgZmlyc3QgcGxhY2U/Cjxicj4KCjxicj4KJmd0 OyBCdXQsIGFsc28sIEkgYmVsaWV2ZSB0aGUgZGlzY3Vzc2lvbiBtYWtlcyBzZW5zZSBmb3IgcGxh dGZvcm1zIGJlc2lkZXMgWDoKPGJyPgomZ3Q7IGlmIHRoZXJlJ3MgYSBidWcgaW4gdGhlIGN1cnJl bnQgb3duZXIgb2YgdGhlIGNsaXBib2FyZCwgdGhlbiB0YWtpbmcKPGJyPgomZ3Q7IG93bmVyc2hp cCBvZiB0aGUgY2xpcGJvYXJkIGluIEVtYWNzIHdpbGwgbGV0IHVzIGF2b2lkIHRoYXQgYnVnLiZu YnNwOyBBbmQKPGJyPgomZ3Q7IHRoaXMgY2hhbmdlIHRvIGlnbm9yZSBxdWl0cyB3aWxsIGFsbG93 IHRoZSB1c2VyIHRvIHRha2Ugb3duZXJzaGlwIG9mIHRoZQo8YnI+CiZndDsgc2VsZWN0aW9uIGlu IHRoYXQgd2F5LCB3aGVyZWFzIHRoZXkgcHJldmlvdXNseSB3b3VsZCBub3QgYmUgYWJsZSB0bwo8 YnI+CiZndDsgKHdpdGhvdXQgbWFudWFsbHkgd3JpdGluZyBzb21lIExpc3AgYW55d2F5KS4KPGJy PgoKPGJyPgpZb3UgZG8gcmVhbGl6ZSB0aGF0IHNvbWUgd2luZG93IHN5c3RlbXMgRW1hY3Mgc3Vw cG9ydCBoYXZlIG5vIG5vdGlvbgo8YnI+Cm9mICJjbGlwYm9hcmQgb3duZXJzaGlwIiBvciAic2Vs ZWN0aW9uIG93bmVyc2hpcCIgd2hhdHNvZXZlcj8KPGJyPgoKPGJyPgpTbyBwbGVhc2UgbW9kaWZ5 IHRoZSBwYXRjaCB0byBhZmZlY3Qgb25seSBYLCBUSUEuCjxicj4KPC9wPgo8L2Jsb2NrcXVvdGU+ PC9kaXY+SSdsbCBkZWZlciB0byBQbyBMdSBvbiB0aGUgYmVzdCB3YXkgdG8gZG8gdGhhdCwgc2lu Y2UgSSBzdXNwZWN0IHRoZSBzaW1wbGVzdCB3YXkgLSBqdXN0IHdyYXBwaW5nIGl0IGluIGEgY2hl Y2sgb24gd2luZG93LXN5c3RlbSAtIGlzIG5vdCB3aGF0IHdlIHdvdWxkIHdhbnQgdG8gZG88L2Rp dj48L2Rpdj4= From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 08 20:40:11 2023 Received: (at 64423) by debbugs.gnu.org; 9 Jul 2023 00:40:11 +0000 Received: from localhost ([127.0.0.1]:45352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIITC-0005YS-Nf for submit@debbugs.gnu.org; Sat, 08 Jul 2023 20:40:11 -0400 Received: from sonic306-22.consmr.mail.ne1.yahoo.com ([66.163.189.84]:44606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIIT9-0005Xy-K1 for 64423@debbugs.gnu.org; Sat, 08 Jul 2023 20:40:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688863202; bh=gz1s0i5M17rJBUKk4XK2MmMw+xbzpp6/JScsvNZc6zA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=gE8jAi8XgzHvq4U7kD9Ay0wmoYfevkLy0QM9NAI+x2nC0g0/em17NX7z/XvgeSRShJOObdU27FMQTtVDNQpAR4M6t/tbs06aDtUKFO6TLe3zbxlmrc/JExfR4trmNVwoNdZR42MO3ltbxWtsXkZ/MZaRRiiPT43/SF2mg6JGLj3KhSXBlg3TWo3HH6Vc/x4FFuh+SgcRbyUXDUWqVLKNk/5ZNM+XOa6VjvZxTllrXBHT9xgcIa6TZ4vZ4z6bnEKrnkaJbso2Q3XnpSk4ZUMr94rP3a3L7wd/nfm03aYujIbIL3pLNomgKWMGZz+rf0h3O6GqwTnVf0Atdk8tzum5uw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688863202; bh=BeTpT8tvRrUyyEBpXnNVp+P51+wI1zlixIDHY8R/L0e=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=BIFh/2Sn2yDDLvSkP0kqCXBKWS4QxefoVCKF9rgUKcQDJqmm3uTYxHysQiy+/tWaehT2mUvguAqSsO543bDbjH8PxaSbfsBUnHsPhhcPH6F80fwQJwyAgxwY+5N4wzXzYgWEohKaC6SYtknsF2kUuJ4l58GNBE+LJWQSO+0UAZ/oE7v3hxZjw9QdLVBTrCmFhWk+kKui586UspuXImkx9ZloOzK3sf7mHe9u0jWHbeAWmRrZgmOjdiTrvj0Y91n9IrljlXjYVdnewx/ECZWxmVuCXpCVYb9DnJLS694jJ/H7OEFIkOM8QQesp7bhknRhsKYnR40eXT9thfEFeMFfBQ== X-YMail-OSG: ymktYJkVM1nw_Nf1g.pdVvTZJLZlEG4tP67yQi9yHyvDD2qMFipvEtjRmBBZ0Fy H1PTHrugKim9MZPBdx_m1VE4qyY4j4AAgTA1y3uCcm529Hu7B7UZIbeO7tlMkB.ySYjASdXREJhh hJ_xNQe3Sh4OAhTiiW5jhpWuyJD6ey6EzXZfZIJrEHgbYN3RPbzqdXw8c86Zy0UTcz5_7u8GRpnL XNce_h0wRZHS7SJ7B9V0Pe1YwvnUUj21Bhdgkbw2a1cb12AGpDEKuLe7B17hwzJbWwaOX0w26Tlg HNczrid8PrncMpwgKm4MV69YLxSF0pgBcwVinB6GKpUPBqypoZrSJGKxGMM7Q1HuCRnfHnXEQwck yvUEcEnJMrlF4dT4a0pzVaQtm_y3TSGbSP0wS4ONgjYmh6IUW69ImqiWKUTO_jEoKwmUwLCdCYmt XFuspzQnGXb0nD0r0L5ei1n30LqbqWrZT3IUWQXLQaYTDfjfWzFr5J4ndWr9pV3bc8DCNISaPBi. C8aJMjC.1PVUqAv7j8AdbClfmOcjKkko5lPbRvTz4jFN85xb_jVeii62GVWFEN7LHFjXFzEPt9A7 12IKblkvqaYN4lv.X17zc4GFdk.PGcbcCXh.xE4SKC_Ihv6_zJ1EhTu4WZWeDyI0zAKioLEjJ6gP NzScTGGvmTf9doZJ4AbOlVmFo_VrFyn0aDJtcS9JuyFHHnBOhITAKTkv3ZMUr4dkecxK9KMTUN4L uglBGEhoSh8bsqB3eeerF2CLh5dWrY9oKcXt3K2uU9lzRosXfCaCrsBVz3vo9Pv96g_EosEsU2oh JD0CfSq6mmQNzwjLEAi27eBHQdqZZGcsAJoyAitwBeO4tDO008LIjwILcvpRmdEEK1im4Y86Ofpp xs5WY6Mz.xsIQP.thS5uto22eaMgz607bWV7O6FM5og8o3h7MFeNMs1rAwaMz6hFTtwHrIoUVXrS NPGXniXYBWQo4ALnATBuKq21FXUN8qkvRlV2eyGO8pldY7G0dhaWXaAW91x_HesUBqCjKU.inGJl 4LQf.0VqDc.EvgcJ9JPuKNmCWEh6ib9YycYsX6o4x26q9Ub6o1ZMIVZB59vmq7V1hW3RoqBMdjZF sY2fYTD8AMefYHTCWFMYPEjXp5pDBubVZt7HD7u5rTi15fZMGo5D48f46ccUg6vLfvdgIOYKWMD5 dabMPlaMdyd3Kuzpb1S48TLbEbrxDkWNTQYgCPEUjc5eVRyBv7SQDHnEC15tDYXV9.oLdid6XIeu bdlZbYiKPsWYhiqmvg2lIeqAXCISE3S.LyoE742qh7WzrZtqcU3IrdDzCHEun9K07yFgvLJ36SAx v0iLjDLeJ.tD.vyuVmbU2GxvoCorQcFAca8QCCs8ZhkZcKxFxIqGi6gIktw_vtLOuBkLLXhLHF0J VRLcn2U2jFOuEfZYzW5PFGbpGxYt5mBXaIq7QvUYls3mWXybnIsmbbsoIydQ6R11JSbBT.0zV6Vy AsVVLViJplj3jt6vEdz1pzj4UEdwTKzdYxq8UTyCt284nLt_d3gCVQ5bN5KIqsfoiRZUD2y1WWgB 00hwmKI_YgAHtN7yMvUXCf4Xduilm5QFBqjEBff3Lq9WZMYECvxBpU8O0G_V0fM4CSkiRFc0a6.f IOdy.xHqw.f8XH9AXxmuYa9YkNQhYfipkoEKwky.B19ZMD7XKNb.fPwJZ4pLZjzTCbGqolxRyy15 Kg3CxHEwd0mOkHW8OPdAs.s3G.VqmD7bMrgIke0A.Y.YrW7nYu9Jw1g36qFbUZCevbgfOT9WbGYA qJuKU_1cb4I8jOxiAXtWH6h2xV_mT7arzppjIowsi1eRs5h4t57SKGFkQxct32NYmeZA0Z73b1uL MZlUbEyq.hKnTydpIhQNuWqxNSjFW6GdSVtHZ5w8DrCRfIOzsJpFrSwRlFnPpjn9C.oh0hYe7cUq VQMzg07p4t6uNbs9jt3VTgzdx405M95eVku34RPhDAXR41QMiQyYOAe7XygspEg8cFVLse6DW4H7 G.1bWcJY9VNqvgWmUjDvN.ekJ6sL6U.LydylQf2fixloYCqbow87Ol__67cop7xmkpdNfyLMMMA6 gERFD2D2WsOzB27M9MZ6JoBiviYZRK_Qa6cR0TV0ZW_sBhZb8OOt33u9p4rlvFhuQwI6CUgadzo8 Gh0uFn3qent.sDSoAs7YB4kD8qv_q1XR8n2g5zInxhZ.EKpzC9W4lnJToF3EG7BBqCo4qLRBLlEb x7cgq1brT.WWx8IFuoylHFZeSusmP0edYl60GXiASVTHeNaFYE68zRMWlLOaMVVjZdg-- X-Sonic-MF: X-Sonic-ID: 251c0a3d-fb5b-4278-bcec-d18956884c7a Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sun, 9 Jul 2023 00:40:02 +0000 Received: by hermes--production-sg3-67fd64777-rc8tr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9627e90dd7c70d9a29e1fcd859dd9b05; Sun, 09 Jul 2023 00:39:58 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83zg46b8fa.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 08 Jul 2023 20:49:13 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> Date: Sun, 09 Jul 2023 08:39:51 +0800 Message-ID: <87zg45ex48.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2800 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Spencer Baugh , 64423@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: sbaugh@catern.com, luangruo@yahoo.com, 64423@debbugs.gnu.org >> Date: Sat, 08 Jul 2023 13:07:37 -0400 >> >> Eli Zaretskii writes: >> >> Cc: Spencer Baugh , 64423@debbugs.gnu.org >> >> From: sbaugh@catern.com >> >> Date: Sat, 08 Jul 2023 16:39:00 +0000 (UTC) >> >> >> >> diff --git a/lisp/simple.el b/lisp/simple.el >> >> index 26944f1f72d..95d00cc506b 100644 >> >> --- a/lisp/simple.el >> >> +++ b/lisp/simple.el >> >> @@ -5618,8 +5618,10 @@ kill-new >> >> (if (fboundp 'menu-bar-update-yank-menu) >> >> (menu-bar-update-yank-menu string (and replace (car kill-ring))))) >> >> (when save-interprogram-paste-before-kill >> >> - (let ((interprogram-paste (and interprogram-paste-function >> >> - (funcall interprogram-paste-function)))) >> >> + (let ((interprogram-paste >> >> + (ignore-error 'quit >> >> + (and interprogram-paste-function >> >> + (funcall interprogram-paste-function))))) >> >> (when interprogram-paste >> >> (setq interprogram-paste >> >> (if (listp interprogram-paste) >> > >> > Are you sure this is TRT for all the implementations of GUI >> > selections? AFAIU, the discussion was only about X. >> >> Independent of that discussion, I think this change should be harmless. > > How do you know that? The prudent thing in Emacs is to "do no harm", > i.e. try hard not to affect any code that is unrelated to the problem. > Assuming that a change is harmless is a mother of all bugs. > >> The worst thing that this change can cause is that a call to kill-new >> can complete successfully when it otherwise would have failed. > > No, I think you can also do the reverse. And anyway, this kind of > "reasoning" is what gets us in trouble time and again. Why risk all > those potential problems, where the original issue doesn't exist in > the first place? > >> But, also, I believe the discussion makes sense for platforms besides X: >> if there's a bug in the current owner of the clipboard, then taking >> ownership of the clipboard in Emacs will let us avoid that bug. And >> this change to ignore quits will allow the user to take ownership of the >> selection in that way, whereas they previously would not be able to >> (without manually writing some Lisp anyway). > > You do realize that some window systems Emacs support have no notion > of "clipboard ownership" or "selection ownership" whatsoever? > > So please modify the patch to affect only X, TIA. It's impossible to quit from selection transfers in other window systems anyway, except perhaps PGTK when the toolkit is feeling generous. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 09 02:11:00 2023 Received: (at 64423) by debbugs.gnu.org; 9 Jul 2023 06:11:00 +0000 Received: from localhost ([127.0.0.1]:45646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qINdM-0006js-I4 for submit@debbugs.gnu.org; Sun, 09 Jul 2023 02:11:00 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qINdK-0006jf-3S for 64423@debbugs.gnu.org; Sun, 09 Jul 2023 02:10:59 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qINdE-0004eI-Jp; Sun, 09 Jul 2023 02:10:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FewQJT027dGFDjgHryl8CQdz7nQpt40k0vOuhOo5dY8=; b=BHURspIVRkdW CXir1sMPO4twwp8GF7fW/Xo1C8nN3P0lW1BrLN1hGXd/naUvGHQ7RnrREtSvjg3jOXfccWXu75qMu E5O2tvoiytA/2j1X2ryeZyxYSNrz95ZrUDc49pPxpswn04QEUjxzQd+Irrtge7YAFC1fc3BZmSkTz ZwUGGK2k2Svc4XpAneZSFzjyqVYiGc+mEaxqCozw+WJuqkQDm9zUUtLYE1Dc2b5Vxs7Jo53Sd19YV lgamLVwW43JXqGBAt1Tqe077DxYuDfy79pkXp/J2WL6I3WWQkO2LFHGbxtxJi2Ly67yg4/HRr2pOH na/WMYZ51VHyWeZYS0w6zw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qINdE-0002qb-3i; Sun, 09 Jul 2023 02:10:52 -0400 Date: Sun, 09 Jul 2023 09:10:59 +0300 Message-Id: <83h6qdbong.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87zg45ex48.fsf@yahoo.com> (message from Po Lu on Sun, 09 Jul 2023 08:39:51 +0800) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@janestreet.com, 64423@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: Spencer Baugh , sbaugh@catern.com, > 64423@debbugs.gnu.org > Date: Sun, 09 Jul 2023 08:39:51 +0800 > > Eli Zaretskii writes: > > > So please modify the patch to affect only X, TIA. > > It's impossible to quit from selection transfers in other window systems > anyway, except perhaps PGTK when the toolkit is feeling generous. Why "impossible"? Part of the processing is in Lisp, so it is definitely possible. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 09 02:13:02 2023 Received: (at 64423) by debbugs.gnu.org; 9 Jul 2023 06:13:02 +0000 Received: from localhost ([127.0.0.1]:45651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qINfK-0006nG-1r for submit@debbugs.gnu.org; Sun, 09 Jul 2023 02:13:02 -0400 Received: from sonic309-22.consmr.mail.ne1.yahoo.com ([66.163.184.148]:42026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qINfI-0006mj-I4 for 64423@debbugs.gnu.org; Sun, 09 Jul 2023 02:13:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688883174; bh=2XkOveNZlwjC1iY9O186dj+UuE6BpBiCX0gMTrRCanI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=Jy82KjP95HdI/R1/x8SmI/y8/SLuqbLZvdc7K0VyHS26uuwfh0E2ZhJXlbBGL7nRwP2hQrriwbZwYb+mb3Mg/7xmN5L/7GKEWqlcwcNG8PiwVqdLarf6NKPpGvxyfYL0VF1KjjyU3KB19KehJl+mIL+EOlwrDU2PCPHPiZe7nkI+Inz2KN3ClZU9V4EfqMIe3zugeXGXsgpraGEArPuCGLNgA9yMg45R1cuXr5ZldNw7V9T9Dh+OACG60lFL2B4nOOq6U+Fi0ziKxtJbHt9ARZizV+TubT1CYGuFy+BY1+P7hCLgpl3l0Bw4LVqVH3IVFJz45EJU8ajWDEclPi5UOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688883174; bh=1Fl/c+bEcdOa6Ci95ONFmtl/+AfEZ+vZr/dksNzjDdF=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=DfXNXMa3BoWuGATqaYlCyRtqImZDmiCQoKbpbx9b1F83FOSA26IxKIDJFczJMkZN64F8v3OJED0qBWt63S/swldLfKrvcqrONupOMowTe+oi8rdpraYe/E3S+EMKXIucx2BecglKAOZ3La1qxl2XIQYyYUV9Mo1THii0MXregAQXRLLKijepsPfxP38yVQNpXm/R70OkfiIuSv4CPnHmmc3iwHEE3ZpIpZWTxDHVBDCSSctqN2zIhWkC6p9pCOWpIf7V40HiTyfdhv6peraLtyOkh/I213cXDYFq938sHTFp2yDiWqizxI6Djx+R1lMfi0YDKwjTxI9JsK+LWJL1pQ== X-YMail-OSG: DYsfoR8VM1lCgQGJC.yoLFhvNCHgLK6pEQfAiB56YuTh4T7kvXScPPbdYlYBb6Y gX4Twdu2PlQd66ESaTOW_tbLqLuwwgJrOFar0F6.15iiWSyo4GfbNLsJLj1BmKIv014I6FzSNB04 WxzNkfoNcihdBsOtLa4v1gc7PHZCrQ0ufeOaDhVqtR_0t4UrHnoCLCr1TDs2OpYj3jEwkaogwoaj xg.BDgdTA0OrJ5tkeKTrrL1FY8SUS0QcKmkfZywh2Coo5d7drhRS73Z18W5VfIXVPUB0PK3jtH5Z oL22FbRdbxbDRWqCXFfvSr65HVyIETe70oFub_jeLvWSejqVrw3oxLr9rZMEHLFlaspqjjWVMuxC 1l2kzm60vhLnsr.sM2ZGwPn7dVuWk7HG7eufGtpr1nHACzpLYM9O_AzOkQPgxo9KwmgXkeHZmuHl Efs8w49sXYWJHRvgUby_Vb2KA5wtE71P07002c3s9CLfNJBvu9keSpisdNYV6d9AvVtFTGxT_DDF zO4y7RkwE953FVm1SybjgW2yzWXHJMzGQjj9fgaWN6qGrcd_wbWT0JYuthIzUktizxMzL2YVSGAj piZ8CA.Rh9AetN9SKq9eeytZ0o.QZADm4keiNRhpURH8fzgZKUnh0.dVUS.i2hf9Gejiwf7TECMw Nu.o.RLjrmHkBeFpGR48o3BvMe3I98N6MBxXPNvK2yiocIxRfQ3t53OHb6cwz6_FdrPXvbaa9Ysq frbm4zzFrPzYNOpPDrasgijYWBGOUE9tsMfsAZVIUKl5vcWMXDERssXa5Xeefp3dDso9xDbBxGy_ Tbb4wafSlr5d7xUkDwYqe1jVPOKFT_bWZS_6dMhoSIfpHitjNu89CedIQ67e5dEMWFF7ir7D6QAV k_fTDmGO25N1tJFl9wsBvBNlCy0VewqMNdwugKKEQPglwYbHfa_DbQS7mby.ZBM1a_igpuDpQYkk fB13fCkk7YKkR5Kw2JHl9J9z.BdsbI5HdECHp41L30bTNWzOsMKkosorFdKD2f6GhEDvCwiZOrg7 pjUxujp2ntSKxKw3yn3Hhx9.ijbmlX0QWoTH.65svbzZ51_Wm8rec29RRxXMfimO6JIqq.bO1ZU_ KgGYEeHOqR24wmRMObA6jz6rxdeVaKefMXW07t.AFRNj3zQKIWKi1IHZdfKV0IN4L8LsEvRBmk7U S1RtSkenDGC7KglJRqtYP.Vkmsn9YTCAphNPpqVaJfW.nz4ub_pYwjl7lwynU17REVVUZw9z8Q9i .Dy.zA5KITmoceio8bR4RWAsQC4zZSst3ptv.kOUgeb.jniAXwOyW_n0m587c_tFM7uT316WFdYp s.vktwbbj0bC8DZ7ogDvgpbbxgtgKQ8vOHCoK2pH0z3uF7Y9w880A_yUd7cmu8U1QIfQOA93fPRz 8XV_qkVzvloLEpT8mBprr7KkY_iEJfjJtqeDkwR1oopPA2XRcRfJTtsBTZW9t_.PvWenMll62i0C Br5_U.MJx3tV5vRfqIg5WT.jOwwuYNtq1Xt6K3xHATTcZjnR0gLIid2Gb.5Q13Cx6NFhOADBvTdt yr4t7TpM01Vg9BiRbKRDJiRee1KICt6c8m2bEC7NSK71SAB_RCIL2Er.4wWOTFQiQFAHi.cbh.Er RCJpUTC0XE.fkrnfUnAlmNFJR3uIS6Ug095i33Q_3.0xwolt3lqMVLGQTv.6qisuKADHQL4u_Bky .dZQ.n9AQP9vvbrMvPDGWLaUfgzCjMLC5X8M8Op1YDWXc5yV.GLFLcoaEfg0lVQ_OepEKPZelRnO 49GTH1zDZmtWujf1bnsKShdNMPA7LSdiLmI5gOnJGcG28AW1YPMkHdsDnf7cJE.OTdsBsXtTJCZ0 1q.ZbZzJsnPq3VMzbvOWFdIvtuIYBretaOLCf8C0zWMJd_X4hNgu7yVosiy4dDnBPz_r4QpyNrb9 _tng.KsAnimmH3WFWkqajWBWmjo1ZCgiHo_fkQaemllW5U9EQkogzyIOk.bkJKwZYKFN9noAt8AO aUlv1WrvPvkca7LI.ycKplttU.ex912zVC040MLBSCTsY4_L5TB4Mqv29tQGcdhdd5FgEU39gYrE Odu3mb9jBahoLSo8d04LsWtuwYdqCs0cjfkWjihqJfLcaLKZCeYJa6UgDA1wuDaLTNaCtgnwgNNd 7wYt4a.u.nRVHFD3hGZLEd_zRI9xHdLQ6MErf2jPCExz.e7U6otoiWQDuk_q0GzAL50NB2fxveR. .is9tHXt0v5Fdkq4333IlGZ5ym2eLRqSJTtcUzPGpUWikQR7kQkatnr7MZOuHSeFLXg-- X-Sonic-MF: X-Sonic-ID: 94d23ba7-ec76-4def-bf4c-1f95e4025533 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sun, 9 Jul 2023 06:12:54 +0000 Received: by hermes--production-sg3-67fd64777-kvs8m (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 97b0147a4f8d495399014cef9b634eaf; Sun, 09 Jul 2023 06:12:47 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83h6qdbong.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Jul 2023 09:10:59 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> Date: Sun, 09 Jul 2023 14:12:42 +0800 Message-ID: <87sf9xehph.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 239 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@janestreet.com, 64423@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: > Why "impossible"? Part of the processing is in Lisp, so it is > definitely possible. That processing is also performed under X. Anyway, I see no need to disable this code on other window systems. From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 09 02:46:28 2023 Received: (at 64423) by debbugs.gnu.org; 9 Jul 2023 06:46:28 +0000 Received: from localhost ([127.0.0.1]:45682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIOBg-0007d8-AN for submit@debbugs.gnu.org; Sun, 09 Jul 2023 02:46:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:34156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qIOBe-0007cu-5N for 64423@debbugs.gnu.org; Sun, 09 Jul 2023 02:46:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIOBY-00086c-9j; Sun, 09 Jul 2023 02:46:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=w8PvII8U7SbdZnpzKM6ESgAt634lLtL5hnMbhbMIBdk=; b=YxaI25X7FetX B25huP1GDy3Yd9v1q2HvzPBDJjZ/BkQQ67NX691/pUYHQt52dQ/HNznc+vr9oVt2dLozl3wvveyxJ OO0mMr1vJBAGH7Wm7/pcXzkDCC4XncSMy/gzKDsDDhZzBUGGw5Nzok4H8mus18qpgawRkQx96sTwN IXLO7XvALn7z3V8slwKoDrzivXwjnX3nDUJLX2kVUcHywVV+Gcvljw4qkuZjnJzsIL2pLmgJ/j27C /dXdnbbso/ALSbfcsG8fnP7QcBexjZd21jCBOZGWuid1GrNvY8L+zP0En6/JPmxrSKPW6/gZ5DcT5 psCfGpd6tsxAx7QvMeFtLg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qIOBU-0003sw-B6; Sun, 09 Jul 2023 02:46:20 -0400 Date: Sun, 09 Jul 2023 09:46:23 +0300 Message-Id: <83cz11bn0g.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: <87sf9xehph.fsf@yahoo.com> (message from Po Lu on Sun, 09 Jul 2023 14:12:42 +0800) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@janestreet.com, 64423@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: sbaugh@janestreet.com, sbaugh@catern.com, 64423@debbugs.gnu.org > Date: Sun, 09 Jul 2023 14:12:42 +0800 > > Eli Zaretskii writes: > > > Why "impossible"? Part of the processing is in Lisp, so it is > > definitely possible. > > That processing is also performed under X. Anyway, I see no need to > disable this code on other window systems. Right, so we agree that a change for this issue should be X-specific. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 12 15:18:29 2023 Received: (at 64423) by debbugs.gnu.org; 12 Jul 2023 19:18:29 +0000 Received: from localhost ([127.0.0.1]:52952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJfM5-0002xg-5Z for submit@debbugs.gnu.org; Wed, 12 Jul 2023 15:18:29 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:35908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJfM3-0002xJ-7m for 64423@debbugs.gnu.org; Wed, 12 Jul 2023 15:18:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=EW/2FNpucRua+dPdVI+w7kCsV7uza4Ld7dg5sShCCk8=; b=KanV6IqKX04bvuCNdlZEOSlcvhlL+/A0xpflIFViZo4oEgdB8cHUzqvPZBXox6bQ8qnY TlQgS3lOvafC7yhxeZ1p2wpsHR/VzgHHAgiKiylWftEZx5rLxZmla6lUXN4z7jLcXGNblc GEUV6tvWAmlegZUbvaaX1je0nkYaboOGSUShZlr66SrcjwQije8fxzmZgMfjWzC3kliInO Ky137vfYSN9MEEW2POKRe5vyxoC6cuXNF8hh9YhO8MJ2hBHiJIzX3Vy/CwqjdbHQwJQO5J 51J/BruIv33bGwmoCdEvnMF8YxjB+NU/sPiHtMoQimtTKd3gXYzhvmooYD2ouepQ== Received: by filterdrecv-66949dbc98-5ngqz with SMTP id filterdrecv-66949dbc98-5ngqz-1-64AEFC7D-30 2023-07-12 19:18:21.724342318 +0000 UTC m=+5427507.929662109 Received: from earth.catern.com (unknown) by geopod-ismtpd-33 (SG) with ESMTP id 5nesv3gJSQWObl_S9G1oUA Wed, 12 Jul 2023 19:18:21.629 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id F2B236015A; Wed, 12 Jul 2023 15:18:20 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83cz11bn0g.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 09 Jul 2023 09:46:23 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> Date: Wed, 12 Jul 2023 19:18:21 +0000 (UTC) Message-ID: <87wmz5j5vn.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbJQtF+YDrTpbT9uRKBYyW?= =?us-ascii?Q?SkMmtAufuf30Jg31S80rvtXzP78HIifsxJFyQST?= =?us-ascii?Q?4u01SwKPdmSSDaJbFshbPQW2YgKUMb48q=2F1qSj7?= =?us-ascii?Q?QysXNwNvVfQox+nE+Y+uOaxySU8vjPKd9LCp3Xo?= =?us-ascii?Q?6D6yHU6iDVuHZDc0de7IZdcgpnu0QFugkxw=3D=3D?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: Po Lu >> Cc: sbaugh@janestreet.com, sbaugh@catern.com, 64423@debbugs.gnu.org >> Date: Sun, 09 Jul 2023 14:12:42 +0800 >> >> Eli Zaretskii writes: >> >> > W [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.3 RCVD_IN_VALIDITY_RPBL RBL: Relay in Validity RPBL, https://senderscore.org/blocklistlookup/ [149.72.123.24 listed in bl.score.senderscore.com] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.123.24 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Debbugs-Envelope-To: 64423 Cc: Po Lu , sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Eli Zaretskii writes: >> From: Po Lu >> Cc: sbaugh@janestreet.com, sbaugh@catern.com, 64423@debbugs.gnu.org >> Date: Sun, 09 Jul 2023 14:12:42 +0800 >> >> Eli Zaretskii writes: >> >> > Why "impossible"? Part of the processing is in Lisp, so it is >> > definitely possible. >> >> That processing is also performed under X. Anyway, I see no need to >> disable this code on other window systems. > > Right, so we agree that a change for this issue should be X-specific. Isn't that the opposite of what he said? That there's no need to disable this code (which I assume refers to the code I added) on other window systems? (Personally I don't care whether this is disabled on other window systems or not, but if it is disabled on other window systems I'd rather do it in a way that is not objectionable to Po Lu) From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 12 20:33:06 2023 Received: (at 64423) by debbugs.gnu.org; 13 Jul 2023 00:33:06 +0000 Received: from localhost ([127.0.0.1]:53060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJkGX-0003s3-SV for submit@debbugs.gnu.org; Wed, 12 Jul 2023 20:33:06 -0400 Received: from sonic309-22.consmr.mail.ne1.yahoo.com ([66.163.184.148]:44465) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJkGW-0003rT-H6 for 64423@debbugs.gnu.org; Wed, 12 Jul 2023 20:33:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689208378; bh=zA31bacUGFqPqwt6YOBpiwaTvA8UTW38al+/T+yXX3k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=o5BDzU0AqynRXl1p5ylidkaNQeR0/e3sXG+qKMQ/j+PMlHmSDUi/Yr/+5MQ1/ReHTu88eE1oMadyGIf8l1/2QEJxD0HyZ0vJRE2l5LkRSEE04v7in+tNnP9Ia9Vo0cQAL163XW6PTYzMteIHkHi7PTygjJq7fdXy9k1FeCm9P+zy2o9C8JvWIBNO8w7CTmpIHiHslyGNMb4Jb9aimagOkTH8qV4tPOUYm1D6ZV6o6BKfElwkTbGa86i0gXndbCu7z7KsilX5DfOfariAivkC46SU2ktV7PIXY0EUBot4C7AB/jVsi9UM/D/ycPYKD8yJfvNnsVbU6aImGOoYumwFbQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689208378; bh=ZzApRGLcz+qUyEEIrjpTAiehzwSsM0qye3UU0Gc0dtT=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=dspNzp8b8gmqBl9LVS0EOjh8J+Orqt+T+KXiC6n9sfTAwu/Gm/jkUUrTpmkLqOF7stXCkEB/xqCtyRHrleVZKJTv3AfoMkmpI80qq+5ew+I1QVPTwJSrIym1TrW3PgLkM+Laf39DH9/bedPEWV80yjPUYwVXcyqW/wM+wxVZ93IWuDPx++qGc+z+AKqZwY7wqmB90wK+FHHlSrdIwDLyMQ2Egd1cWHtJKfitQ6tkfuFL9DRda+ygQJGKbjnxGwSwVab0oH0k8kxIwpRCTdoTPm8a+oUL2rad37LkOMLFRrsV9UJ9CYwFfqJi/5vSe0vghuwfqWf1kD1/TcR/s5QSxw== X-YMail-OSG: 04R7kDcVM1k7K4VbRV7dXbCVsUwwXNv.HKcWai976Rb8ijl7gk_tEFqdYzM11u0 inv4z8iedRh2GjkPli0tyBrjQVll73ZBraJ9hLBO9ykYQ5xBhO28yx8o55XfL0lt7qoYCsL4Lg1w tK69M4dBA.x1fWGtJpX0BQZBmXuZpC8s5A_6EJjv3CTzKXr2BdVPhit_xquzgXEpnBA4d0Q0zfUQ 1O0xQC5gDO2fib2BuD6k1Rw1WLCHBQbvZLM3ZxgUaANNBCQmRYUNLzPext81.48A8BNzo2T9OlL8 h6ZYE1hULUuyj4WPx6kd_N6KbaO94WYlvHScLRKBFtK.XDRq0IQ77.Mf5dm5pySYaCBtHJwFcAqX 34JM3_guX0FyKb7evslafA.Yq.h53tVlmtyo75epedHmRlUTDtRz6piOvwaRnriD41HO2jdkAtTp 5sbmTgS8IS6OG5Eoz95SUIbbxq.xt0fw4IwPNcgOLa5DaUs_F3VTxsHcmUgWXow6aqmRV6fITBdW O7th_pB.hBabt7Zz9j2l0FEOF7xiY0c2acS5LFWlLYz7ldL1NSKpyeOkKZ3qAgw_pi9EgysZLM8j Mb1h07M908PQVt.HLhVil6IPoBQ24pPv8r.NSr.qYpbc2jyVgHDBA5V4P5bpZsj7JZ5MtJ3n2g7Q LldARpoXfwyJvaEbycLmykk4ny3StQbN.ETZmxIFfSW4U38f.eVmtNhDGgD8feMWxW4H.cA464AD 41kZqtQT1Xv_M9332LHS.fRW3gBGMI9vS9QNtFqpnoC9bkFnEuu.xzK__YfDt_m_.9AfzWe78Vmp nVt0JcFjIR.T5TzXxa3XSo3RuK3e1XqvwUoMSYfvTyihv58QuD38uKodJDxYaQjrGvO_HzsYzAxt MlGTuwPdtcVrxDx2jp1IjsfdhOixt6UjbJCc7rXyJ5dmoCRuWDPUmm8bhMT1lqPPSvpm6rULmNgF p5vA3oNMKim75sTLSdigh8TCN0x0MSHw10ri7UKBLgDvlAIwp5udf0gNoygTeHI7NDavXrodLDiM jKPdFXe1DNxG6Iqi5S96AtnpkepiZkaDVnxr0Cru.TskKMdoFLrAGW2uwBcAA3DSVC761uJbICHR sdVZhzzCr4pOykdPqy8aeMxL.7mg4M40Shm6.wDEzKs_dZ2M36M36HPf6dAVNx_aHcdLwbuKemIj 38UkYR9_oF7_uCRxhjoAZKTTH7KXESxyjcHm5azkQhMVtvMjNX7C2m1SRk3Bxo4u9Er0lHrXQhMk EaXMKnEOhrMf2y4sV.jELRyi1UaFL44znW5V.wGBz1zJfKcgJ2owKKOrcmTW0SbN8wUKXgG5QdLn .HplejKKUJepQFIONrMdCSaLuWuJ0hviugPYGNFI53ce9OPvN7yMUDpe7u7ENIYJAkzgBGPO5rAW Gv6KAQEZRZGTB8IRo7IjF.Rhsp6g.X7tLwhnWC2YFKSYsoTINtE_UnVgSiR8Mlrrgqt88ttTwsRx 9ZtOTYLf8Jaw7j6cVW875vR0RekuRcgwt8PrhI6AeNuHMFfcceg3NKOTTIuEJ_xTcWctJDkPtddc 4nwdeC6A937viE4nQgtSPQIqAbz2ViqZTYafBcgT9Vdig.GQLzr4dkruA2t1NnDPXG8ZaSNVkIom pbxFoJVG.RapwMCjYZFDhFyVjB7XzPj7COIYmaN3YlagI9wPRTwX.zju4A3eXsCWq3RvO.eC1jaQ pCm1SJpj0jxUOnfYDJRWHzwN9CkNmjZwxVbLBmsm9.0nNUeXr1IIJIdsn6niJJUcnQT_MCvzSUwD 3TVbmqM1qPux0UBMpIW1eziBe5aew4ZSX4PYksI5lhMtkDT7xkz4DW6Dt7XZu1KYR8yDY3g9nLuO 6xfVFtldeQUac0ROdkwkwFDlR6Zob0j80C2TPN4j2aAE1jspkODpRrJLb45YBAxChvxENKJruTp_ ZqwkigiyL3.W5IkD3CLxUnHAu4qO.OCDQhXIgooAAbTSKkET27Z5CY_it2tPNF5xwgHARfxQFWvh MTxBuChbxejYnBVOuqq2ImxXt1PHlN6oZIFHKUs_jbRN9NQuE7ZT5FHWcTz8i6KFQe6POuxkb3dr b1R6u0_wGxD3B_76jgrP2v_XBNbz7pinIYO7YHRFm5IznJxVdIYDN7RHOB19R1QuGfaKO8NTW.Ik 56dzj.6mmTbJfHzI5m.2VUVNibmANfVZT6HHRzkJ_SGnMgkdiwYXN9BmgSmyf4oJZgRqlE2M0rYN 5egMH6jPq_f47lHmgm3cSVjUB6GQUABBoJnKvp9zaS5lueuP_jgSZjexWRU5IjBE- X-Sonic-MF: X-Sonic-ID: e0173215-5107-47e6-90eb-ae8434868f40 Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Thu, 13 Jul 2023 00:32:58 +0000 Received: by hermes--production-sg3-67fd64777-t6vwt (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 2fa70e6c8bdc8af3f2d54f0aa7aa51b3; Thu, 13 Jul 2023 00:32:54 +0000 (UTC) From: Po Lu To: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <87wmz5j5vn.fsf@catern.com> (sbaugh@catern.com's message of "Wed, 12 Jul 2023 19:18:21 +0000 (UTC)") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> Date: Thu, 13 Jul 2023 08:32:49 +0800 Message-ID: <87351sbqha.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21638 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 204 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@janestreet.com, Eli Zaretskii , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) sbaugh@catern.com writes: > Isn't that the opposite of what he said? That there's no need to > disable this code (which I assume refers to the code I added) on other > window systems? You are correct. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 13 00:48:13 2023 Received: (at 64423) by debbugs.gnu.org; 13 Jul 2023 04:48:13 +0000 Received: from localhost ([127.0.0.1]:53141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJoFR-0002Zw-Ci for submit@debbugs.gnu.org; Thu, 13 Jul 2023 00:48:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJoFM-0002Yp-KN for 64423@debbugs.gnu.org; Thu, 13 Jul 2023 00:48:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJoFG-0004jT-IC; Thu, 13 Jul 2023 00:48:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NP5T6c8gQqk2SUddGO8VBCu5UXtED638G7ixWqqYcoA=; b=eyp/qJQd7/LA r7QASblNXPl8b+1CJATHfMiuGYQvhf2MWFbB0Q4m0fktLa6mjy+Szzlzr09W7HiqbVWB3b+lqyEfq YsOssUqQOVQrWycfUGBD2UXcLAi0JaYUHSPDhqt+db8nTu0pb0+BP/vu+P/IEJnf4Nr2J6n+YD1UK cJBSS+YA9bo0uAEBjuEen288MBruwhZP9nlqqrUIeeUuDXXFL5kftJNUfMEee377khAe/cKiZlMvm 7lsrZq4xTnOWqC8Clev079m9plHFPD13wmSvO4/NiEaI6i/q0yFdUmHJuwis0boXQ09I/lQ43KL2h FNBqXP1rYrf7hrGvqkzucg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qJoFG-0004oS-0Q; Thu, 13 Jul 2023 00:48:02 -0400 Date: Thu, 13 Jul 2023 07:48:18 +0300 Message-Id: <83pm4w5sdp.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87wmz5j5vn.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Wed, 12 Jul 2023 19:18:21 +0000 (UTC) > Cc: Po Lu , sbaugh@janestreet.com, 64423@debbugs.gnu.org > > Eli Zaretskii writes: > > >> From: Po Lu > >> Cc: sbaugh@janestreet.com, sbaugh@catern.com, 64423@debbugs.gnu.org > >> Date: Sun, 09 Jul 2023 14:12:42 +0800 > >> > >> Eli Zaretskii writes: > >> > >> > Why "impossible"? Part of the processing is in Lisp, so it is > >> > definitely possible. > >> > >> That processing is also performed under X. Anyway, I see no need to > >> disable this code on other window systems. > > > > Right, so we agree that a change for this issue should be X-specific. > > Isn't that the opposite of what he said? That there's no need to > disable this code (which I assume refers to the code I added) on other > window systems? If that's what he said, then we don't agree. > (Personally I don't care whether this is disabled on other window > systems or not, but if it is disabled on other window systems I'd rather > do it in a way that is not objectionable to Po Lu) You can do it in a way that is not objectionable to either of us. It is very simple: make the changes conditioned on X. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 13 12:17:39 2023 Received: (at 64423) by debbugs.gnu.org; 13 Jul 2023 16:17:40 +0000 Received: from localhost ([127.0.0.1]:40668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJz0d-0004jL-I3 for submit@debbugs.gnu.org; Thu, 13 Jul 2023 12:17:39 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:49792) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJz0b-0004j5-VP for 64423@debbugs.gnu.org; Thu, 13 Jul 2023 12:17:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=yCumUHZdzQXTmWsnxDelKZvBXJQcpe3sP+Q2GAb0ka0=; b=mq71xIXN8xeobCtCfP9+T3/o/A5CgmGVsUVAHcmax1fu0G5b5mgD2iM9TpzIPnyIod7B lzYgvifiRfavi11ASluSozFipGWe4ahyvi8jwYctmNhxM08JS9NTEVgdD4xPhbl/GZW2Fj yDvh3WG+Q3BVwHIS4Vaz48qZLk8Fl/2XvNTC7H55M5xBJJ2lT6dVZ7C70uqPQAet7kuXcE q5fPKfXDQZT3/u5JiottWqqmralqirSTjpWvTUF9/d1b+QhZeHzXPBrFZYfY7UaqQO3nUc 8/ONHBqMp2eap9EGCEVeNdYp+09318Y07ebW6gfCWadLglbzyXk+mIcq+rg4ECRQ== Received: by filterdrecv-77869f68cc-5zdvl with SMTP id filterdrecv-77869f68cc-5zdvl-1-64B0239C-15 2023-07-13 16:17:32.242961848 +0000 UTC m=+5503290.040817803 Received: from earth.catern.com (unknown) by geopod-ismtpd-27 (SG) with ESMTP id Kkw8ot4HQrmMpW96XWo5sQ Thu, 13 Jul 2023 16:17:32.168 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id C11CA6009C; Thu, 13 Jul 2023 12:17:31 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83pm4w5sdp.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 13 Jul 2023 07:48:18 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> Date: Thu, 13 Jul 2023 16:17:32 +0000 (UTC) Message-ID: <87jzv3kcpw.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbJ=2FxuduLktfpMJYGrpSkR?= =?us-ascii?Q?ayO=2FH6u=2FypRLypVYvJ=2FgirAStMobO5NeWTMamJ0?= =?us-ascii?Q?bYOcz464nFZAChk5KNh7uGV0DenlaEjknGEo+Y+?= =?us-ascii?Q?XE1V7U=2FJZrOtEgqHqnOQOFlGWAzeX+accXOIooH?= =?us-ascii?Q?dIRk5g=2FyJsZju6Rgj2I6ipHmsvAAs5gbCHg=3D=3D?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Wed, 12 Jul 2023 19:18:21 +0000 (UTC) >> Cc: Po Lu , sbaugh@janestreet.com, 64423@debbugs.gnu.org >> >> Eli Zaretskii writes: >> [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.154.232 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Wed, 12 Jul 2023 19:18:21 +0000 (UTC) >> Cc: Po Lu , sbaugh@janestreet.com, 64423@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> >> From: Po Lu >> >> Cc: sbaugh@janestreet.com, sbaugh@catern.com, 64423@debbugs.gnu.org >> >> Date: Sun, 09 Jul 2023 14:12:42 +0800 >> >> >> >> Eli Zaretskii writes: >> >> >> >> > Why "impossible"? Part of the processing is in Lisp, so it is >> >> > definitely possible. >> >> >> >> That processing is also performed under X. Anyway, I see no need to >> >> disable this code on other window systems. >> > >> > Right, so we agree that a change for this issue should be X-specific. >> >> Isn't that the opposite of what he said? That there's no need to >> disable this code (which I assume refers to the code I added) on other >> window systems? > > If that's what he said, then we don't agree. > >> (Personally I don't care whether this is disabled on other window >> systems or not, but if it is disabled on other window systems I'd rather >> do it in a way that is not objectionable to Po Lu) > > You can do it in a way that is not objectionable to either of us. It > is very simple: make the changes conditioned on X. OK, how about this? modified lisp/simple.el @@ -5618,8 +5618,11 @@ kill-new (if (fboundp 'menu-bar-update-yank-menu) (menu-bar-update-yank-menu string (and replace (car kill-ring))))) (when save-interprogram-paste-before-kill - (let ((interprogram-paste (and interprogram-paste-function - (funcall interprogram-paste-function)))) + (let ((interprogram-paste + (and interprogram-paste-function + (if (eq (window-system) 'x) + (ignore-error 'quit (funcall interprogram-paste-function)) + (funcall interprogram-paste-function))))) (when interprogram-paste (setq interprogram-paste (if (listp interprogram-paste) From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 13 14:39:47 2023 Received: (at 64423) by debbugs.gnu.org; 13 Jul 2023 18:39:47 +0000 Received: from localhost ([127.0.0.1]:40827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK1EA-0002lb-JQ for submit@debbugs.gnu.org; Thu, 13 Jul 2023 14:39:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK1E5-0002lK-KN for 64423@debbugs.gnu.org; Thu, 13 Jul 2023 14:39:44 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qK1Dz-0002cq-0a; Thu, 13 Jul 2023 14:39:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=f7xhdQXva9fIsRerM3jt/yffvUC4ZTfps/H+u4qgJZM=; b=kO9+cqZLZz6v emaYywsfK8+4r5YaqsPcfqzgrXlVEMC64+dTbyyC2gT8uRTpJBK5+hCk/gHBbNx07iHBqy/4y9Dk+ ukGbKAxgEHhrXNWcT9e7vaM7xgRRJZjOLGKVyoPac7VIZGCbcwfOYpUU00rK9c+zN+V1ra5Fv3Ais tA11/a1XbznraT+Fn7F1vSt5wMxLN4+FzvJ4rY1fu4t3w/P6Cucqy+FxiM6k5XFaVGAvrRHWiZBef eVzjGtWKe+EeB7YGY7kCcQC8SG+U0XsAUW6muUXeL30kwd5R7WOqf0GMMrsaky/duYw6UtrmT/dqR FRtc650alDSOp5hHlP2fzQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qK1Dy-0003vt-Cp; Thu, 13 Jul 2023 14:39:34 -0400 Date: Thu, 13 Jul 2023 21:39:51 +0300 Message-Id: <83o7kf4pvs.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87jzv3kcpw.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Thu, 13 Jul 2023 16:17:32 +0000 (UTC) > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org > > > You can do it in a way that is not objectionable to either of us. It > > is very simple: make the changes conditioned on X. > > OK, how about this? > > modified lisp/simple.el > @@ -5618,8 +5618,11 @@ kill-new > (if (fboundp 'menu-bar-update-yank-menu) > (menu-bar-update-yank-menu string (and replace (car kill-ring))))) > (when save-interprogram-paste-before-kill > - (let ((interprogram-paste (and interprogram-paste-function > - (funcall interprogram-paste-function)))) > + (let ((interprogram-paste > + (and interprogram-paste-function > + (if (eq (window-system) 'x) > + (ignore-error 'quit (funcall interprogram-paste-function)) > + (funcall interprogram-paste-function))))) > (when interprogram-paste > (setq interprogram-paste > (if (listp interprogram-paste) Fine by me, but please add a comment there explaining why we do that on X. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 13 18:39:18 2023 Received: (at 64423) by debbugs.gnu.org; 13 Jul 2023 22:39:18 +0000 Received: from localhost ([127.0.0.1]:41010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK4xy-00011l-A4 for submit@debbugs.gnu.org; Thu, 13 Jul 2023 18:39:18 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:1384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK4xw-00011W-4r for 64423@debbugs.gnu.org; Thu, 13 Jul 2023 18:39:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: cc:content-type:from:subject:to; s=s1; bh=Nevp6FkSxI/pBJdLKaEyvnR+jgxag3btCgE0bUAAiLE=; b=N9LAOQeElFcNgtmsv8xe0PT4KNK4eD6p1oUOOIj6Dk4z6rkBJvuGxq72vwPUfpkEiLG+ P7TKQw81/3qp1IBKwr4Ur1ZU9du5o+6sw2gzkDvAhrWREo7k4q7Irv0cNrDYbLI9K8pi6T 8YZMEBGUQlBWXaSmDV9jcz3Ii7gTkP8QovGIPtbBf4JIfsgL4GpH3TVJ9zMv5Yd2RRhpFk Cg3QzoLbq9yyJKHpHo6yJa5LUyKXbP4o+BNiTzxr2+8dqynSDtPkCRpwYrhUs8iEQG++AK cV7vf5SSCbZhiJYoOwukAPxaGKPIqcIB1L82XR1CFVP3QkreDQLHL9H5fnsDsFtw== Received: by filterdrecv-66949dbc98-s5rnx with SMTP id filterdrecv-66949dbc98-s5rnx-1-64B07D0E-17 2023-07-13 22:39:10.594367626 +0000 UTC m=+5525973.671765098 Received: from earth.catern.com (unknown) by geopod-ismtpd-19 (SG) with ESMTP id vqsEwZsDQteRqO3iY_dnvw Thu, 13 Jul 2023 22:39:10.543 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 047AB60075; Thu, 13 Jul 2023 18:39:09 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83o7kf4pvs.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 13 Jul 2023 21:39:51 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> <83o7kf4pvs.fsf@gnu.org> Date: Thu, 13 Jul 2023 22:39:10 +0000 (UTC) Message-ID: <87edlbjv1u.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbJ7eovYVBy+uIkYc+0Ipa?= =?us-ascii?Q?1kHCGzSKLBcWXSCwu6rwJmQO6litoNcVw=2F9ac=2Fn?= =?us-ascii?Q?SvrqM8HyKUSrJtSD28E2nrZovMF90ST1psUDUtJ?= =?us-ascii?Q?vfBHZ8V0BEBj7gG5iHILxNEyM5Q+fxSgHLxa2sF?= =?us-ascii?Q?IvkG39JiENzqF9zqXbsSXTHkiFxBmzrk1uA=3D=3D?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Thu, 13 Jul 2023 16:17:32 +0000 (UTC) >> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org >> >> > You can do it in a way that is not objectionab [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.123.24 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Thu, 13 Jul 2023 16:17:32 +0000 (UTC) >> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org >> >> > You can do it in a way that is not objectionable to either of us. It >> > is very simple: make the changes conditioned on X. >> >> OK, how about this? >> >> modified lisp/simple.el >> @@ -5618,8 +5618,11 @@ kill-new >> (if (fboundp 'menu-bar-update-yank-menu) >> (menu-bar-update-yank-menu string (and replace (car kill-ring))))) >> (when save-interprogram-paste-before-kill >> - (let ((interprogram-paste (and interprogram-paste-function >> - (funcall interprogram-paste-function)))) >> + (let ((interprogram-paste >> + (and interprogram-paste-function >> + (if (eq (window-system) 'x) >> + (ignore-error 'quit (funcall interprogram-paste-function)) >> + (funcall interprogram-paste-function))))) >> (when interprogram-paste >> (setq interprogram-paste >> (if (listp interprogram-paste) > > Fine by me, but please add a comment there explaining why we do that > on X. > > Thanks. OK, comment added, here's the patch. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Ignore-quit-while-getting-interprogram-paste-in-kill.patch >From 4d669af4c6273d5c7ca229353c5056e3969f84ae Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sat, 8 Jul 2023 12:36:22 -0400 Subject: [PATCH] Ignore quit while getting interprogram paste in kill-new On X, if the current selection owner is not responding to selection requests, the user may want to take ownership of the selection. The obvious way to do this is to kill some text (which a user might also be doing just as part of normal editing at the time the selection owner becomes nonresponsive). However, if save-interprogram-paste-before-kill is non-nil, then killing text will hang until the user quits, and this quit will abort the entire kill-new, preventing the user from taking ownership of the selection. Now instead if the user quits while we are attempting to retrieve the selection from hanging owner, we will proceed to take ownership of the selection as normal, resolving the problem. (One example of a selction owner that might not be responding to selection requests is another instance of Emacs itself; while Emacs is blocked in call-process or Lisp execution, it currently does not respond to selection requests.) * lisp/simple.el (kill-new): Ignore quit while getting interprogram paste (bug#64423) --- lisp/simple.el | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/lisp/simple.el b/lisp/simple.el index 26944f1f72d..b97b5dd1725 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5618,8 +5618,14 @@ kill-new (if (fboundp 'menu-bar-update-yank-menu) (menu-bar-update-yank-menu string (and replace (car kill-ring))))) (when save-interprogram-paste-before-kill - (let ((interprogram-paste (and interprogram-paste-function - (funcall interprogram-paste-function)))) + (let ((interprogram-paste + (and interprogram-paste-function + ;; On X, the selection owner might be slow, so the user might + ;; interrupt this. If they interrupt it, we want to continue + ;; so we become selection owner, so this doesn't stay slow. + (if (eq (window-system) 'x) + (ignore-error 'quit (funcall interprogram-paste-function)) + (funcall interprogram-paste-function))))) (when interprogram-paste (setq interprogram-paste (if (listp interprogram-paste) -- 2.41.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 04:30:49 2023 Received: (at 64423) by debbugs.gnu.org; 15 Jul 2023 08:30:49 +0000 Received: from localhost ([127.0.0.1]:44084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKafx-0002hn-2Q for submit@debbugs.gnu.org; Sat, 15 Jul 2023 04:30:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42742) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKafv-0002hV-Ik for 64423@debbugs.gnu.org; Sat, 15 Jul 2023 04:30:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKafp-0001ph-QR; Sat, 15 Jul 2023 04:30:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fWIyh3spffs73ngCZ2C3TFe2izTUgkQ9nC3V9J9e2Oo=; b=P4TpR8+GjZnb /RbsM1dJyehduezwREx0EcMDjq3PoKZK9nD4sHv3nRknuenT0VTRXgtU5osrbqFV+2HLxUgImQsdP l7Rol6AWBmSMi4oyMjdTDj7Y/UqQCqoa2KAykrLHIctHXqMDkrGIcYjxX9MrlV7oTpL1taJr3SGy3 QZfxB/EU8DZP83kMmPrOXiuXR7FTCfsF40prLEnH4YeuGssmmXLySnQt5M9V6HajNb99O6z2psA0T 82twogqIzNajtEfBq0s6Bd9yp+wEPMfPRoNg0Zfw4dw51hGilW+5hSwGcpqEhBYQU8f04eYAs1iOi mzCQ1albkuhQwqFRi9s7Tw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKafp-0005CS-8h; Sat, 15 Jul 2023 04:30:41 -0400 Date: Sat, 15 Jul 2023 11:31:02 +0300 Message-Id: <83mszxd1a1.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87edlbjv1u.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> <83o7kf4pvs.fsf@gnu.org> <87edlbjv1u.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Thu, 13 Jul 2023 22:39:10 +0000 (UTC) > Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org > > > Fine by me, but please add a comment there explaining why we do that > > on X. > > > > Thanks. > > OK, comment added, here's the patch. Thanks, LGTM. Po Lu, any objections? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 04:33:34 2023 Received: (at 64423) by debbugs.gnu.org; 15 Jul 2023 08:33:34 +0000 Received: from localhost ([127.0.0.1]:44089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKaib-0002mL-LH for submit@debbugs.gnu.org; Sat, 15 Jul 2023 04:33:33 -0400 Received: from sonic302-20.consmr.mail.ne1.yahoo.com ([66.163.186.146]:37162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKaia-0002m8-D0 for 64423@debbugs.gnu.org; Sat, 15 Jul 2023 04:33:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689410006; bh=fedgzsK2uvfxMnIBGA/+NejNSWR3FlSgRJJgA7jEpyw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=p65jM2RWQYEMjLhhZbYCSvA6zr6787agNFsnP4Q+H7xE5Gd7I2/SqsvXaf/nd/K8RKloxjvXrhNOHgzmzmTlQ2qhcgZJJzJ3XooqmZnH4j+T2dDPagJO4/yq3YVtSbuHVewPu/Cmt4DbHRrBa8OqbVtpecK0xmtolgVGwkMZjkeWwF5DG9XwGmQypdDwWRy7LJQ4TCT7BnRwkRNDnDB33i7eLFpbvE7Ry6FCV8Hg3xFUczUzqufIBZNtlCD8vJWZteigoXlHHjj9l0KxtlXxC4ouqqs7/+Mdj4HgMMbbZX65uBCey/sfNpFjJEJgPTt1qZrd04gZejkSOtsyC+W2Lg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1689410006; bh=zOZbJOQI+163o9h9wvSSu3YTkGnSAzxYU08K9I1TLjU=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=qqaARWw8158UVUbpYsh7PEc+++ccoaz4H25D3hxFB1+zDO4oTxyemylXwYx32zF8Y7w/RY98qMvlKWjxyUNsLYXMRWJ9RdmfDsEEwxZsYjVUqsS/nqUEFpX9KBmKKkCV84VBkpoYPL7DqP9DTkBO3pTQ0hrxcV8fuhq9dS4zd96zJfxTUmA7jOXNA0kReeP48xoJ9pzOBmN7PCwx4wABo40lpNKLaiFGS9U/TvskcozN4rlBo6Cx7/mlnfZf6npJ2J4RnuxQ1wJyz8B+hdyfNhR7vzUnnmKFAKeQh2ZIsBQp7TS2vV7BbMDJAxb/4nbmEsx88/k6udeU09MABiMfIQ== X-YMail-OSG: BlJeEtwVM1l9.uo38HJt.gZd2zkna5xPt2P0d40XGwlZMerPXpUyByD5FNFRStm 8.RzjV0mIYojWosz1LF.QOrRR39pQN6PhtKmyjaEmlotIIk4ESd9e3rtmWXMmpggMjiQKJoIpJI6 Bu9BVyGRpT9qnbXHXlgDZKUtIGrtTEniu0xkUbA6GEzk3r5855EH0AfhPqwiZdXSz8SOq5IY7nSb kQMs7R0a4T.tl.TG.ScGGvscYJ27mzXg3Q00mIP9u3fLtA3WPXngR3YmXggY3ej2PEQ5at3K4zXh RgWyfanLbHywBwY.wqmBqktxTjfqZZwr6x9RczDfytENPUAdfGzboubszjcSVn7T1wYauvP6gPwE PVzA_K32ZXh7iPPFH9h9WZf94h5pN9QNFZ7Gb5zLnSIrWCPbUxl.xWqcB6G4echrxbBLAD6_QB3V Y0HeEi7DRw_eURSG5447AQMpauFIE2KbFOP4ZHwouUcUySL0MXgz8xXK5NL8TDki2IsNTd0ejrzz wjWNvREceul2SHY37roIu8FQMM0TnTyyxencmWpIasVn.JEUcNWPgN51VYDoGWgKPwkPti5o6YSe KoTcpb.lTJ2QPgWlmWOADp53z79ezwobzuI6MtJbHw3uk2E.vkZgDgUOfZiKUxX_8jK7OBHHf0cB U0QW3jsTtG8bLUCIn8M4tGxD5Uk6UPVgCCUG0rFtVZzC2wRIA_sKxUfTD2z3LkMQ5sgQSoYpWRjO JYEyPJLjbraGEZBOKE0NNkgmK6BEjNSfn1cdlusu.P7HO8_DPkZC18maHHqF.BCpf4XJGNS6r8j1 v_EbfOFC2sdA1Pk2YqlXTC.aHySI5uzuWH9uZUg1rQ6L1vMBhRWWmmAkyCBIRWP0kIpZtpsxgd0h 4DVYoLqZV215yDY5w0XNo0Xoy5IQHNhBigQGml6IJ8csWUUVDzUR7Q8DMdwc.JwCpuwPmINpRkju v3nkk1evoAQHXxcki8pS1tnWWyUKBsxOfhLHLLwRdLxdrRipox17feULZrAvQx6FBJg8fddJR0DH mlzpi_ibI_AaEkvpOQnRXBXrhodjnOUMECRkpwGAB.cYryheKzrvpVNgM3g4lQgDUCrByX3MFEZN 7xURlXHvjj5GHDEw2iXg0mnA0uPcssHZRkhxhaNvZgcj1wegfAFGda.VxOxqh16f8MqT5GCut9Yd m0kw54qemyJ5VqADANoolKOa2eFpP4nlE2QopoXaaqYWna4syhNHLWqZhTpAQiI83vu98nlEauuR AKINVW5N7xKMAWl2sFGdSHPzaevhcEo6jOUiArhqg8gjfc90rQG3spOilQhXFPZYv18gZOYbj01p lv10w12.ehEIp8_ynQeocQ76H10SqdgYPCmyszqzAEWoCPvgQhp721Z4FY0.ft.hJg0iIlsUHUix 1eSvJMeSGA_hwr_s4Eatt9vwlY6OdfoszrasrthSa_PRNrkstPWrci8s3uX.pTqWONw8rKi.ya7c qYk_OUvRDF3FS07orjbPxls6EcMYZf_T.MC_J_7Yh5QFvgusAqf4JmCCSXrdCIS9q8qxSPaHKpC0 9V6dIy3lerxyAlj16yYbEWR6uAGv6jtb7nUtRh4LKjLk1kk6ZvNskbp8T7BRn_CjUjD87Rjd44Fn Brvd1gw9slNhJrM_9U93mbvdgQSwaLLHaoz4A51pcRCn9y4vf4lxzWo6SZaYJ2FJP8dcuD.MB7_M z2jgPK84ox8Y5AQd_fG6o8Ey8UZ8NpyzShrMqrsG6phbVQqQbGgq4x08tVnFVL1Ijjz10rLHN2D8 d4eANEpYCRJTYEBpzgvbYaSEeSE7Z2c7knNUtcPnHCtcN_FEPa5GALDanzre0.4twFBjZCoU8hqd oGbUyk1_W.T95HOxjgChEvteX1hmy02CdGO.b4JBSZAHtPvx9z5M.H3lCe3A.j7v_1U7AS2Y2rK1 _cbVU4eLomnSXmYt8wvrhONfEF_MI42M_fg.FjuCV10D9nXxOBh8HRGtuD545JMba1q8biKU7sOh jIXz6SQykP_P5JfBn4QYTWbix8JbxoX.bV_9xg4eCZFsWD7813lbFWCaSXc4vyGSb6W9v2jRlM0K 3sUGo0hJu03kaGoLwWpnsEfaJuOOfcHJQT8QbJhznCqIS.2NyFAIA18xOmYzBgQD.wKt6BUVMsA5 gEIkcDnuS8eIDl4lXw7C7aHlcDNeIm2mZ7pOE9gyVbbPyk7U3RSM1Ubo_MoHU97ILMubU7w7_kVh fPAu1gc8ewjkIFMCskG5y2PjuMVdEO7TYjr0Idfyyv2AJFQaof8PS8ZU- X-Sonic-MF: X-Sonic-ID: f60e4d9c-9b7e-48e1-8d75-d3a22a8958f8 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sat, 15 Jul 2023 08:33:26 +0000 Received: by hermes--production-sg3-67fd64777-szq9p (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 89155de572312e015f9520ea0a9a26a3; Sat, 15 Jul 2023 08:33:22 +0000 (UTC) From: Po Lu To: Eli Zaretskii Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83mszxd1a1.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Jul 2023 11:31:02 +0300") References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> <83o7kf4pvs.fsf@gnu.org> <87edlbjv1u.fsf@catern.com> <83mszxd1a1.fsf@gnu.org> Date: Sat, 15 Jul 2023 16:33:13 +0800 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.21647 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 427 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: sbaugh@catern.com, 64423@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Thu, 13 Jul 2023 22:39:10 +0000 (UTC) >> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org >> >> > Fine by me, but please add a comment there explaining why we do >> > that >> > on X. >> > >> > Thanks. >> >> OK, comment added, here's the patch. > > Thanks, LGTM. Po Lu, any objections? None here. Please go ahead and install it. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 05:01:17 2023 Received: (at 64423-done) by debbugs.gnu.org; 15 Jul 2023 09:01:17 +0000 Received: from localhost ([127.0.0.1]:44128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKb9R-0003XF-An for submit@debbugs.gnu.org; Sat, 15 Jul 2023 05:01:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKb9P-0003X3-Kg for 64423-done@debbugs.gnu.org; Sat, 15 Jul 2023 05:01:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKb9K-0000RD-CQ; Sat, 15 Jul 2023 05:01:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=UPQyaFym0J0Yk+v4MNUWytKNBaAJpaQ5EqrjRc2kwpY=; b=SVH25Kg/P0mN c1xxdSEwnEe3tmGjvGd+n6c22yoE9Ympj5Pf1Bxa8jT9BOAf7T9qyjeIoPC7VEitUEnOmzdCP4Yxy ki7szpd9pzSR3LTUfVlji2gCYjQiOhu8RG4igjmeuucPjJ1buTaYm/n/uWlIpO88vR+Hfg2AS+txH +JzCh7l3t8GjbGwKzle2cZ/p+xb35dFV0pc7QGl74UO73Oq2uHGmVmYhJhruJav4l8kJEp6IMTllO X+BDsH9zGQ5ReGevIB7kFmA1RrfNMcTQdp+1JejivtM3wDnY6TkmRo4hyRAxleKLeYxs7jQXB3reF OKEG3iMcjBUQWTS2dD3F+w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKb9J-0005an-SW; Sat, 15 Jul 2023 05:01:10 -0400 Date: Sat, 15 Jul 2023 12:01:31 +0300 Message-Id: <83fs5pczv8.fsf@gnu.org> From: Eli Zaretskii To: Po Lu In-Reply-To: (message from Po Lu on Sat, 15 Jul 2023 16:33:13 +0800) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> <83o7kf4pvs.fsf@gnu.org> <87edlbjv1u.fsf@catern.com> <83mszxd1a1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423-done Cc: sbaugh@catern.com, 64423-done@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Po Lu > Cc: sbaugh@catern.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org > Date: Sat, 15 Jul 2023 16:33:13 +0800 > > Eli Zaretskii writes: > > >> From: sbaugh@catern.com > >> Date: Thu, 13 Jul 2023 22:39:10 +0000 (UTC) > >> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org > >> > >> > Fine by me, but please add a comment there explaining why we do > >> > that > >> > on X. > >> > > >> > Thanks. > >> > >> OK, comment added, here's the patch. > > > > Thanks, LGTM. Po Lu, any objections? > > None here. Please go ahead and install it. Thanks, installed on the emacs-29 branch, and closing the bug. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 05:35:41 2023 Received: (at 64423) by debbugs.gnu.org; 15 Jul 2023 09:35:41 +0000 Received: from localhost ([127.0.0.1]:44168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKbgi-0004Ud-TY for submit@debbugs.gnu.org; Sat, 15 Jul 2023 05:35:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKbgg-0004UN-KC for 64423@debbugs.gnu.org; Sat, 15 Jul 2023 05:35:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKbgb-0004B8-Db; Sat, 15 Jul 2023 05:35:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=/uClqemLZWRvzf8Ag9EG2jSFjFK4+cCucVwYnOT1pts=; b=eEYM7eMwmaeq1b8DxOL/ gyJFGLlj3SrWJWsM4XYvY/BEqOZvvVUQEuTFsAVZXi6t+Q9LkDLekV4Ry6h9ZWFH40BcIN+4UR9v1 BiDL7+691R2DdaU2MHbgigzfTTGosZjlBbUG5pB2CSsCwlpQCmig+eKmVpqJjmPLO0El4U/xMMNqz zSOz1k2+59rqX87ALlgEim8IIxm0Qh5G22zWXMJ9yjETGtDtrK+cmE4SG5RQ1fgKaVZ0qndGyyIma idGQISo3PqX/KjUSmS4AtspTn2faTLkBFqOsW9kRgTVfBl5LYyRbOe6z5R448Jl9MrUJz7VzseYEu qLvNFRv6txa2WQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKbga-0003rT-TN; Sat, 15 Jul 2023 05:35:33 -0400 Date: Sat, 15 Jul 2023 12:35:54 +0300 Message-Id: <83a5vxcy9x.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <83fs5pczv8.fsf@gnu.org> (message from Eli Zaretskii on Sat, 15 Jul 2023 12:01:31 +0300) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87cz193eno.fsf@yahoo.com> <87jzvgse4k.fsf@yahoo.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> <83o7kf4pvs.fsf@gnu.org> <87edlbjv1u.fsf@catern.com> <83mszxd1a1.fsf@gnu.org> <83fs5pczv8.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Resent-To: bug-gnu-emacs@gnu.org > Cc: sbaugh@catern.com, 64423-done@debbugs.gnu.org, sbaugh@janestreet.com > Date: Sat, 15 Jul 2023 12:01:31 +0300 > From: Eli Zaretskii > > > From: Po Lu > > Cc: sbaugh@catern.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org > > Date: Sat, 15 Jul 2023 16:33:13 +0800 > > > > Eli Zaretskii writes: > > > > >> From: sbaugh@catern.com > > >> Date: Thu, 13 Jul 2023 22:39:10 +0000 (UTC) > > >> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org > > >> > > >> > Fine by me, but please add a comment there explaining why we do > > >> > that > > >> > on X. > > >> > > > >> > Thanks. > > >> > > >> OK, comment added, here's the patch. > > > > > > Thanks, LGTM. Po Lu, any objections? > > > > None here. Please go ahead and install it. > > Thanks, installed on the emacs-29 branch, and closing the bug. This causes the following warning to be emitted (on master): In kill-new: simple.el:5660:38: Warning: ‘ignore-error’ condition argument should not be quoted: 'quit From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 13:38:15 2023 Received: (at 64423) by debbugs.gnu.org; 15 Jul 2023 17:38:15 +0000 Received: from localhost ([127.0.0.1]:45954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKjDh-0006q4-1T for submit@debbugs.gnu.org; Sat, 15 Jul 2023 13:38:15 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:44058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKjDb-0006pg-Nw for 64423@debbugs.gnu.org; Sat, 15 Jul 2023 13:38:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=8eeuwODubmQCDmfE2RGIBOxLN3hudV1jc+x6pS3Bc+0=; b=TCyjpFmjvoYplsHFjKivWpCLwyh96NbH8A86Opa0ddlSuDTpR/BsVf8QUh6SgW8sTzxo AgjUaRmHG9rEqBb56/6pNw3QIaKBBOZByZmqC3upd28RWFmlKmJgC+msretTNI+0rf8u2o Z8LqrCZkDi6tbdNlS7nOM5yK0w1WAleSaLJ82zT4oTAQoyWDzN874vrTgsJb6CxBOJn1vo eybuV9LkrykATN4tbCWf+RRHSxnOJLTtQV+7ufRJNkvzKArdR1KYvOQJYpAjtSzPQtp9ic /MgNzXSUXJQCMgZaFSHGy4jInF4E/hwXOX7pdTbtVlH0TR79M/CClno4RZTQOgkg== Received: by filterdrecv-77869f68cc-l7kjz with SMTP id filterdrecv-77869f68cc-l7kjz-1-64B2D979-21 2023-07-15 17:38:01.799196923 +0000 UTC m=+5680924.883658357 Received: from earth.catern.com (unknown) by geopod-ismtpd-41 (SG) with ESMTP id UCFYjngRTMKDKTg-iaGXtA Sat, 15 Jul 2023 17:38:01.703 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id F1DAC60075; Sat, 15 Jul 2023 13:38:00 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <83a5vxcy9x.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Jul 2023 12:35:54 +0300") References: <875y72ieq8.fsf@catern.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> <83o7kf4pvs.fsf@gnu.org> <87edlbjv1u.fsf@catern.com> <83mszxd1a1.fsf@gnu.org> <83fs5pczv8.fsf@gnu.org> <83a5vxcy9x.fsf@gnu.org> Date: Sat, 15 Jul 2023 17:38:01 +0000 (UTC) Message-ID: <87wmz1hy87.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbIjlhxQE0K9QWKjsKp42d?= =?us-ascii?Q?08uu46ntWsmRk0jEoQ4i2vUqjdWPAC2ZDabKn=2Fc?= =?us-ascii?Q?NcV3f+Ch4LiffdMPZgfcF5M5z8dOyAbDlE3rqcS?= =?us-ascii?Q?82TlBR+HT4uZTlUQH4MNEYRDbnCFhK0zeENhdOM?= =?us-ascii?Q?hMUolCQ1boVNp5wQpcAO5n20yUhflENQ2bQ=3D=3D?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Resent-To: bug-gnu-emacs@gnu.org >> Cc: sbaugh@catern.com, 64423-done@debbugs.gnu.org, sbaugh@janestreet.com >> Date: Sat, 15 Jul 2023 12:01:31 +0300 >> From: Eli Zaretskii >>=20 >> > From: Po Lu >> > Cc: sbaugh@catern.com, sbaugh@janestreet.com, 64423@debbugs.gnu.org >> > Date: Sat, 15 Jul 2023 16:33:13 +0800 >> >=20 >> > Eli Zaretskii writes: >> >=20 >> > >> From: sbaugh@catern.com >> > >> Date: Thu, 13 Jul 2023 22:39:10 +0000 (UTC) >> > >> Cc: luangruo@yahoo.com, sbaugh@janestreet.com, 64423@debbugs.gnu.or= g >> > >>=20 >> > >> > Fine by me, but please add a comment there explaining why we do >> > >> > that >> > >> > on X. >> > >> > >> > >> > Thanks. >> > >>=20 >> > >> OK, comment added, here's the patch. >> > > >> > > Thanks, LGTM. Po Lu, any objections? >> >=20 >> > None here. Please go ahead and install it. >>=20 >> Thanks, installed on the emacs-29 branch, and closing the bug. > > This causes the following warning to be emitted (on master): > > In kill-new: > simple.el:5660:38: Warning: =E2=80=98ignore-error=E2=80=99 condition ar= gument should > not be quoted: 'quit Sorry, here's the fix: diff --git a/lisp/simple.el b/lisp/simple.el index 54e71e1b040..6dc08ff0eb0 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -5657,7 +5657,7 @@ kill-new ;; interrupt this. If they interrupt it, we want to cont= inue ;; so we become selection owner, so this doesn't stay sl= ow. (if (eq (window-system) 'x) - (ignore-error 'quit (funcall interprogram-paste-func= tion)) + (ignore-error quit (funcall interprogram-paste-funct= ion)) (funcall interprogram-paste-function))))) (when interprogram-paste (setq interprogram-paste From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 15:12:11 2023 Received: (at 64423) by debbugs.gnu.org; 15 Jul 2023 19:12:11 +0000 Received: from localhost ([127.0.0.1]:46092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKkgd-00010i-Jj for submit@debbugs.gnu.org; Sat, 15 Jul 2023 15:12:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKkga-00010V-TU for 64423@debbugs.gnu.org; Sat, 15 Jul 2023 15:12:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKkgV-0001Fh-IZ; Sat, 15 Jul 2023 15:12:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=VhcJGbD7BMZ61q3QnHQyYA4vc5EUu9biocu0dYAXwmw=; b=eDf79XAiTLnG0whQtqwq 8EZEf87EemrH9KulN2s9e1FQ024UBVlUs5OHHwE6rrzSaJpYInKfep6Bond1GK1cL8mlS7HUyUI4N /hcrVI36AqKAk+H/v0ox+wUarZAAxEwgg0PXb/RK3ODNmdBGxrHJVGBRaUnaRmV5JOmPmvn+SEPbS 18Tbtn1zuTD0yFrPiNVCPNJWnFM5gp8xrb92Xx7QDdMOXEm8rKrSekR4JrKcdZRGwllEcG1xdjBG5 XJtk3/rC7bRqyJvLQqk3knb6wSlOPfadQGNMNF4PEgeSJmudqlREWy7FhItLP6dugYChzaJHxaHsM 1gNzWRTUHicJag==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKkgU-0001Bl-NL; Sat, 15 Jul 2023 15:12:03 -0400 Date: Sat, 15 Jul 2023 22:12:25 +0300 Message-Id: <83fs5pat0m.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87wmz1hy87.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections References: <875y72ieq8.fsf@catern.com> <87pm58phyu.fsf@catern.com> <87y1jwqqel.fsf@yahoo.com> <87mt0bq4py.fsf@catern.com> <87mt06mk7w.fsf@catern.com> <831qhicpsy.fsf@gnu.org> <83zg46b8fa.fsf@gnu.org> <87zg45ex48.fsf@yahoo.com> <83h6qdbong.fsf@gnu.org> <87sf9xehph.fsf@yahoo.com> <83cz11bn0g.fsf@gnu.org> <87wmz5j5vn.fsf@catern.com> <83pm4w5sdp.fsf@gnu.org> <87jzv3kcpw.fsf@catern.com> <83o7kf4pvs.fsf@gnu.org> <87edlbjv1u.fsf@catern.com> <83mszxd1a1.fsf@gnu.org> <83fs5pczv8.fsf@gnu.org> <83a5vxcy9x.fsf@gnu.org> <87wmz1hy87.fsf@catern.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 64423 Cc: 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Sat, 15 Jul 2023 17:38:01 +0000 (UTC) > Cc: 64423@debbugs.gnu.org > > Eli Zaretskii writes: > > > This causes the following warning to be emitted (on master): > > > > In kill-new: > > simple.el:5660:38: Warning: ‘ignore-error’ condition argument should > > not be quoted: 'quit > > Sorry, here's the fix: Thanks, installed. But does this mean the original change was not really tested? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 17:00:25 2023 Received: (at 64423) by debbugs.gnu.org; 15 Jul 2023 21:00:25 +0000 Received: from localhost ([127.0.0.1]:46188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKmNM-0003vf-QQ for submit@debbugs.gnu.org; Sat, 15 Jul 2023 17:00:25 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:35968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKmNK-0003vP-8E for 64423@debbugs.gnu.org; Sat, 15 Jul 2023 17:00:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=subject:in-reply-to:from:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=jAa8WJ8opM6A+QiHZpsnLvJD9c/5WEHgA0D7Fj8VDs0=; b=OwlcuhNPkSAJaFhMhPryRvZFI1qKWaGRYFa5LvhiA9vtWxerssMTHWGnY/P61PsVuNJH nWNA+NvlGuOMDU5cOnb5VdzlogT6dWLPGIctZOhn/pZJN8Op5NEDp67wFnp0SykqdpM3A3 M4z4mBi63guw+Q0zMtqZS0im3XHnze8pRVF0GHU1MlctZl/2W0andoxcQpLEqoO0sV+yfE L/HfLjrJT4Oq1HMnLZBdGD0hgpUvaxfn5imbeMD1QWQZpXfBy8NFDzS8H3qmkJmGy6JDML iUZuEdVhw/9DrByzTUlAcQsdAz6VBoM+i5Qiig3KsP8Io9zCpc3GlfYf109aZtlw== Received: by filterdrecv-65f68489c8-k2rl8 with SMTP id filterdrecv-65f68489c8-k2rl8-1-64B308E0-48 2023-07-15 21:00:16.5710418 +0000 UTC m=+3531611.840796812 Received: from earth.catern.com (unknown) by geopod-ismtpd-12 (SG) with ESMTP id jF8d7YrxRduUMUspbjyvag Sat, 15 Jul 2023 21:00:16.518 +0000 (UTC) Date: Sat, 15 Jul 2023 21:00:16 +0000 (UTC) Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections Message-ID: <05a5debd-c698-4d2f-b1eb-a95837b1a36d@email.android.com> X-Android-Message-ID: <05a5debd-c698-4d2f-b1eb-a95837b1a36d@email.android.com> In-Reply-To: <83fs5pat0m.fsf@gnu.org> From: Spencer Baugh Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cO?= =?us-ascii?Q?rI4e0V+MFZgakz9Re5a6=2FCggK9AgnbdOtt+PYLD?= =?us-ascii?Q?KiHz92lbODkwjhYmCtwyOKFC8HYrlDV5BWoMBbg?= =?us-ascii?Q?=2FlLw+x1QLiKrHlWv0ybdCBQa2JZKJCALNmuhmh=2F?= =?us-ascii?Q?55=2FB3ZuSu825Gy2XLQg9rzM6fG6flhsdhCnUqu6?= =?us-ascii?Q?CdBoIORAmYM3FIyHcxPanJkqyNJlm6vCzw+JZy?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 64423 Cc: 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.3 (/) PGRpdiBkaXI9J2F1dG8nPjxkaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+T24gSnVsIDE1LCAyMDIzIDE1OjEyLCBFbGkgWmFyZXRza2lpICZs dDtlbGl6QGdudS5vcmcmZ3Q7IHdyb3RlOjxiciB0eXBlPSJhdHRyaWJ1dGlvbiI+PGJsb2NrcXVv dGUgY2xhc3M9InF1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4 ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PHAgZGlyPSJsdHIiPiZndDsgRnJvbTogc2Jh dWdoQGNhdGVybi5jb20KPGJyPgomZ3Q7IERhdGU6IFNhdCwgMTUgSnVsIDIwMjMgMTc6Mzg6MDEg KzAwMDAgKFVUQykKPGJyPgomZ3Q7IENjOiA2NDQyM0BkZWJidWdzLmdudS5vcmcKPGJyPgomZ3Q7 IAo8YnI+CiZndDsgRWxpIFphcmV0c2tpaSAmbHQ7ZWxpekBnbnUub3JnJmd0OyB3cml0ZXM6Cjxi cj4KJmd0OyAKPGJyPgomZ3Q7ICZndDsgVGhpcyBjYXVzZXMgdGhlIGZvbGxvd2luZyB3YXJuaW5n IHRvIGJlIGVtaXR0ZWQgKG9uIG1hc3Rlcik6Cjxicj4KJmd0OyAmZ3Q7Cjxicj4KJmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7IEluIGtpbGwtbmV3Ogo8YnI+CiZndDsgJmd0OyZuYnNwOyZuYnNwOyBzaW1w bGUuZWw6NTY2MDozODogV2FybmluZzog4oCYaWdub3JlLWVycm9y4oCZIGNvbmRpdGlvbiBhcmd1 bWVudCBzaG91bGQKPGJyPgomZ3Q7ICZndDsgbm90IGJlIHF1b3RlZDogJ3F1aXQKPGJyPgomZ3Q7 IAo8YnI+CiZndDsgU29ycnksIGhlcmUncyB0aGUgZml4Ogo8YnI+Cgo8YnI+ClRoYW5rcywgaW5z dGFsbGVkLiZuYnNwOyBCdXQgZG9lcyB0aGlzIG1lYW4gdGhlIG9yaWdpbmFsIGNoYW5nZSB3YXMg bm90Cjxicj4KcmVhbGx5IHRlc3RlZD88L3A+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2 PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPkkgdGVzdGVkIGFuZCBp dCB3b3JrcyBmaW5lIGZvciBtZSBib3RoIHdpdGggYW5kIHdpdGhvdXQgdGhpcyBlZGl0LiBJIGd1 ZXNzIHRoaXMgd2FybmluZyBpcyBqdXN0IGEgc3R5bGUgdGhpbmcuPC9kaXY+PGRpdiBkaXI9ImF1 dG8iPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+ From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 17 12:43:27 2023 Received: (at 64423) by debbugs.gnu.org; 17 Jul 2023 16:43:27 +0000 Received: from localhost ([127.0.0.1]:50825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLRJn-00029O-GB for submit@debbugs.gnu.org; Mon, 17 Jul 2023 12:43:27 -0400 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:51681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLRJj-000298-Te for 64423@debbugs.gnu.org; Mon, 17 Jul 2023 12:43:26 -0400 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2b702319893so70621921fa.3 for <64423@debbugs.gnu.org>; Mon, 17 Jul 2023 09:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689612198; x=1692204198; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:from:to:cc:subject:date :message-id:reply-to; bh=gHQQekrNUIEaMtvgArufOk/sh+bTYclIIBWO0ZMnBxg=; b=ioQYY+PHoujy+TSDxbwb037BTnpKY79MMyAsXOU6zk5StPDIvMOvbwq2zdLmcehODO F5qLw75uUJHUYIzboqX8qVOjkuXKQwKLCw+7xekuNNgYgIRDOCx9hi3gg+FvBquBvDl/ HjhUkqEmUAw7Mq6WMQk4KOCdxoCHiLaTnasyXmKQmFihO9fo4D0q7Gnax3bTrY3hVGsY 1rcXO4RfbeGjLdZmx3k3maT6uWIq0U+i6ufQ4xjS7lr0weT7LgWg/O/5e9dEAjYLvawb b7IsqHxd34wHL5k2dOJ3NYiGwrPQOqdQ1LU3A5z4PneUVxExZ45JJnwEFNHjpd6m+7g9 uPjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689612198; x=1692204198; h=to:cc:date:message-id:subject:mime-version :content-transfer-encoding:from:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=gHQQekrNUIEaMtvgArufOk/sh+bTYclIIBWO0ZMnBxg=; b=fepA5znteoFq6gaOxOUIPByZ1L6GwFhhBpDOKSPLhNZmF39vEEh4NfBPiWATwvRXv9 a+b2VQJyz+Kh8M4qIs4ZLahxzzcMNERF7HcQdHkpbCziOySZFbDE8KA1cG7kzNG7Z+qS wy2lI5TNuioZcTvLPqBDkjkWtA4PdYyE7QC6vn/NQcZ3D88Uggn6bgFV4BNikmDjcsUb h7zZqZ9d/IBxzYlWir7MudGLc9NVInkmbl28ZvGdfq6hQRDi+Uu9iN74kZSEfV0Vsmk4 8JJcutYD/B0j4aD6R1W+OBuc9KxSOi4kOR4gehMx+hpfCdRp51bIqaOqJzJXSAG4FX/9 lVKA== X-Gm-Message-State: ABy/qLaV9kjmf06+9u/e2OgaXfcY4nAWVlxNOMGxEnP5CxZUXVx8Xkmy VQFoVY79eWYRckimHrplEZY= X-Google-Smtp-Source: APBJJlHeYMgufKcuwHG5jBmlfsY+7x+kRgUIiY+s9GKND+3qCJq6DvEtSBODitu8mlEh/4T7AjLt9Q== X-Received: by 2002:a05:651c:106:b0:2b6:c886:681 with SMTP id a6-20020a05651c010600b002b6c8860681mr8354005ljb.6.1689612197725; Mon, 17 Jul 2023 09:43:17 -0700 (PDT) Received: from smtpclient.apple (c188-150-165-235.bredband.tele2.se. [188.150.165.235]) by smtp.gmail.com with ESMTPSA id m10-20020a2e97ca000000b002b6e863108esm2616ljj.9.2023.07.17.09.43.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Jul 2023 09:43:17 -0700 (PDT) From: =?utf-8?Q?Mattias_Engdeg=C3=A5rd?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Subject: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections Message-Id: <77C27A3F-D441-4AB8-855F-AE58763185AC@gmail.com> Date: Mon, 17 Jul 2023 18:43:16 +0200 To: Spencer Baugh X-Mailer: Apple Mail (2.3654.120.0.1.15) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: Eli Zaretskii , 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > I tested and it works fine for me both with and without this edit. I = guess this warning is just a style thing. An ignore-error argument of 'quit is reader sugar for (quote quit) which = will ignore both conditions `quote` and `quit` which probably wasn't = intended. It works but is a bit wasteful. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 03 11:53:38 2023 Received: (at 64423) by debbugs.gnu.org; 3 Aug 2023 15:53:38 +0000 Received: from localhost ([127.0.0.1]:52759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRadu-0001Iy-HM for submit@debbugs.gnu.org; Thu, 03 Aug 2023 11:53:38 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:54191) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRadt-0001Ij-Gv for 64423@debbugs.gnu.org; Thu, 03 Aug 2023 11:53:37 -0400 From: Spencer Baugh To: sbaugh@catern.com Subject: Re: bug#64423: 29.0.92; save-interprogram-paste-before-kill doesn't prevent streaming large selections In-Reply-To: <875y72ieq8.fsf@catern.com> (sbaugh@catern.com's message of "Sun, 02 Jul 2023 14:13:04 +0000 (UTC)") References: <875y72ieq8.fsf@catern.com> Date: Thu, 03 Aug 2023 11:53:30 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 64423 Cc: 64423@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) FYI, just for completeness and to help future users, I managed to track down the original source of this "large selection" for me, which was causing gui-get-selection to hang. It's this bug in xrdp when an image is copied: https://github.com/neutrinolabs/xrdp/issues/2763 This actually is just a hang with no data, not a large selection. So in the end, preventing the streaming of large selections wouldn't have helped. The patch that we did end up applying, to ignore quit in gui-get-selection in kill-new, works great at mitigating this xrdp bug though. From unknown Tue Jun 17 20:21:37 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 01 Sep 2023 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator