From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72830: Big rectangular selections are slow Date: Sun, 22 Sep 2024 10:12:44 -0400 Message-ID: References: <3F6C6CAB-8CD1-4336-B1D1-949E716139FE@gmail.com> <1B4E9D0B-2223-42D9-BA22-17A5F6F49F84@gmail.com> <0D0565B4-EF53-43B6-9B33-7EE1600E1AD3@gmail.com> <5F6C5DCE-88F0-446D-8CBD-5E9EE26FFFC6@gmail.com> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17693"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Michael Heerdegen , Eli Zaretskii , 72830@debbugs.gnu.org, Juri Linkov To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 22 16:14:05 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ssNLf-0004T5-7K for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Sep 2024 16:14:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ssNLK-0003Qc-Dt; Sun, 22 Sep 2024 10:13:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ssNLJ-0003QP-H4 for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2024 10:13:41 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ssNLJ-0006nw-2V for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2024 10:13:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=bVUIQMK/BbQRpZ6GOthzqhUO48OVdjWd6hMEvvWE/Xw=; b=Xlx7MGLSrk3fdTO4XSmO2hKZual9+CeTPltjIo/n54W5i/kG6Hxr+oPSUNi7f38EqFluxxp1tCDwUGOvHv+C19+isWLfcVESmxGM5E4Df6HhaY36W87DfW3sk+G38RTejgc+fZe+65RedZ3Lkd0bjWWoVIvFCCtKSh2JUnhbo7lodBRZ/pLx7j65vGjub9gx6rts0vWSXKHAeYBem4FQ8NldPrgFdJP3KHVz1DbSG1yqw7J46TerAlKyscz02Q8e7WlPOfGyrDJYemG2cMjKb0OG57wguYCBb/UqNnJX6JSoz6YiUEBOYuNZ8Wgos6IokXgrqtWinpwGcpKHN6fFUQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ssNLe-0005ay-Mn for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2024 10:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Sep 2024 14:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72830 X-GNU-PR-Package: emacs Original-Received: via spool by 72830-submit@debbugs.gnu.org id=B72830.172701439821426 (code B ref 72830); Sun, 22 Sep 2024 14:14:02 +0000 Original-Received: (at 72830) by debbugs.gnu.org; 22 Sep 2024 14:13:18 +0000 Original-Received: from localhost ([127.0.0.1]:42611 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssNKv-0005ZV-Tz for submit@debbugs.gnu.org; Sun, 22 Sep 2024 10:13:18 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssNKt-0005Z6-Rm for 72830@debbugs.gnu.org; Sun, 22 Sep 2024 10:13:16 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 085C780982; Sun, 22 Sep 2024 10:12:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1727014366; bh=xy5ZYngKIviflvYFgK2INp3cQeb67Q5RChdZglwOwAw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=e36446ZJ3gVMQvsTRZmM+kU0KCMUAT1WSavuc0FsXPIMkjX1uN3kyDrl1w0EGsaSU vzpDthtwR62Svf7lTmWRU/FHEIx1hkQrnFZLvcI+OI5C+aqXArM++H59pMnVa5qE4a gWoB0NGb1T1mNeQUNutbdTgwGAH12pllmnrGpBf55X3m0rfY/wo1w8YWJvUIk3yb6m j458yEz4gG1Tiz8xtMaI3TzyGgCkaqY6hjjZDEFP8bxp4MclAN0DhplcKtf3YQNMnb O8UAP8cPmiX07wyieEmuffN/gj36Vqt4SjC5tBWuui5A25MGQVcjm0slgi4xmsfUR3 61jIZs6oeqg9w== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0611380187; Sun, 22 Sep 2024 10:12:46 -0400 (EDT) Original-Received: from pastel (unknown [45.72.221.103]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A696512045A; Sun, 22 Sep 2024 10:12:45 -0400 (EDT) In-Reply-To: <5F6C5DCE-88F0-446D-8CBD-5E9EE26FFFC6@gmail.com> ("Mattias =?UTF-8?Q?Engdeg=C3=A5rd?="'s message of "Sun, 22 Sep 2024 15:27:50 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292234 Archived-At: >>> - `select-active-regions`: as mentioned, it slows down rectangle selection >>> massively and is alien to non-X11 platforms so I'd suggest it be set to nil >>> by default on macOS and Windows at least. >> I think we should first try and make it not-slow, by making it lazy. > No objections there but we would need to rework some plumbing. Emacs's behaviour is odd. > When a selection is made, that text is extracted and squirrelled away just > in case, so the user can actually select some text, deselect and move > around, and even make some changes the the buffer, and then paste PRIMARY > from Emacs or any other X11 client and still get the originally > selected text. IIRC from the last time I looked at that code, I got the impression that the design was made [pun ahead!] primarily for the CLIPBOARD selection and *should* work something like this: - when we make a new selection, we tell X11 that we own the CLIPBOARD. This should be an O(1) operation. - when the selection changes because we move point or mark, we don't need to do anything. - we get the content of that selection (an O(N) operation) only if/when X11 asks for it. - in order to still be able to send the CLIPBOARD's content after the selection has disappeared, we pay the O(N) cost when the region is deactivated and "squirrelled away" (like you say) that content. So the big rectangular selections should slow down only steps 3 and 4 but not step 1 or 2. And as you point out, maybe step 4 could/should be skipped for PRIMARY, tho I'm not sure in which cases it would be beneficial (beside those cases where the region is so large that the O(N) cost is a problem). Stefan PS: Of course, if needed, maybe the step 4 could be made faster by squirreling away not the exact rectangular region, but something that can be computed more quickly and from which we can later still extract the exact rectangular region if/when needed.