From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#72830: Big rectangular selections are slow Date: Sun, 22 Sep 2024 17:16:20 +0200 Message-ID: <3413563D-0343-4764-8D44-DAE3D3642A80@gmail.com> 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> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7378"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , Eli Zaretskii , 72830@debbugs.gnu.org, Juri Linkov To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Sep 22 17:17:59 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 1ssOLX-0001oT-Ga for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Sep 2024 17:17:59 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ssOLG-00064r-1t; Sun, 22 Sep 2024 11:17: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 1ssOLE-00064Y-JZ for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2024 11:17:40 -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 1ssOLE-00042D-AZ for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2024 11:17:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:Date:In-Reply-To:From:Mime-Version:To:Subject; bh=HxgG9suXztCl4cnBSVp7WIqiZ0xNc5yHtIvFc7Humjg=; b=UrLD6fnkNQxrP6tn0Y7upSUaaZ9PVckIp8DmndvvlCE+btsZjtni3SD6odNtiEnyPW5FSUGFPou8d5eulcLW4weitcwV5QxtPaTH03uyegp+M984FOCV8iq2RefNm8VaaxxgRl4yD4SYAjXeCt/psewi0Zdc1U+M5z8yApQ6GZe9Jk9fulRwr8uuBQfueq5EXU/kf1v7gscVB+EFiICNgGOVpcpufss+h1bFfR+GcUFRvhY48HEnNUqulyTkStDVV7lWs0E/RuYZveoRL29wRy5KsRPCpPSBcnOYTeg6uVxQeh1Ku7sodYAvrj4Ddrmtk78LaR0dVQhPNVPsMP+/OQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ssOLZ-0000rN-KK for bug-gnu-emacs@gnu.org; Sun, 22 Sep 2024 11:18:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Sep 2024 15:18:01 +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.17270182753291 (code B ref 72830); Sun, 22 Sep 2024 15:18:01 +0000 Original-Received: (at 72830) by debbugs.gnu.org; 22 Sep 2024 15:17:55 +0000 Original-Received: from localhost ([127.0.0.1]:42645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssOLS-0000qz-DQ for submit@debbugs.gnu.org; Sun, 22 Sep 2024 11:17:54 -0400 Original-Received: from mail-lj1-f178.google.com ([209.85.208.178]:57595) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ssOLO-0000qh-K2 for 72830@debbugs.gnu.org; Sun, 22 Sep 2024 11:17:53 -0400 Original-Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2f75c6ed397so36580091fa.2 for <72830@debbugs.gnu.org>; Sun, 22 Sep 2024 08:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727018182; x=1727622982; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=HxgG9suXztCl4cnBSVp7WIqiZ0xNc5yHtIvFc7Humjg=; b=LmcCp5/xlQdH/7HHzVqjCRivHVTYrJErGR/FiU0P84R1BE4Ufb1K/MUKKX1FcKGqdl TuOeLTd+9r3UcXx072gWdmM3JV/ch5u1bkbju7+jRRla1KWRknMe2zGwlbkrvE3grIz8 31tlPM6QYRlMTeH6fGSEAwAJJEkvnu3R0TmVxjBn7RDuIFpJPytMvEvk/F/+xJMwP428 dZAtjPQm7SeLSqkAbRBq8vDaUvMvwVwlIwFQBFubEginq/P8PC2jEldF0A8rfK3fwy98 /HLctwKs/o9+yLeTEeOTb0+MNnW/tUPyJmD1pNpxmvvZYqN1r00kVXUzEFTlIhnRrh8l f0nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727018182; x=1727622982; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=HxgG9suXztCl4cnBSVp7WIqiZ0xNc5yHtIvFc7Humjg=; b=Hw9UQ8mpg9PLVDiRAr79YS80PpXkIRqH3X2Hr5BxCTglbEW7J7C9u5BtYlP9Nql4Da MuXlUZyjNGR3ehwb31/ab9RchNFP2pGiINxTlwgp23trg+qKoPLu/ktqmf/ocnGFFxrO /6IYsJHakTnYIh6GuEnnupO+Bw/6mA7x/QD9fepyO736eY8dsw8zw4kriVxkiomagxxW bbeYcWtDEs3Rny76r4LGOEsJ+00ZfbsOIVZ+lox79IcnrWduOcWwpVvLrqHj0Bm8yFbc lJjXcZUrX0NI8p5lpzTHx5YJa1mNcDhAkIDgOj7RGKOxjKwyINo1YS9kcr4WmX+lQj1i gCyw== X-Forwarded-Encrypted: i=1; AJvYcCWp40TdlVMxGP5Fu3kjVAbLltv8Z1Q+zIgpCRPRarKzUNxWPHQZKH4GUZ61VUdSuYF6jjt/hg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxcywDnHG8aZMbvEcll9KS4+GG92A3JWDrUlJSLxKt2biFlhSBo PvscjW4Av2rSuscwA2GnH/xiH/mK2QzTPDNk26rRgafP0QWDJ1tt X-Google-Smtp-Source: AGHT+IHjOZ+ZeSZuA3fgoXdOHljdXTn074BOepm2uE1lOoZjPot+/ESd2O0jSSQisfL35jTvZnQPMg== X-Received: by 2002:a05:6512:1395:b0:533:4505:5b2d with SMTP id 2adb3069b0e04-536ad3e2061mr3977548e87.60.1727018181999; Sun, 22 Sep 2024 08:16:21 -0700 (PDT) Original-Received: from smtpclient.apple (c188-150-191-82.bredband.tele2.se. [188.150.191.82]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-536870b8c46sm3026393e87.280.2024.09.22.08.16.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Sep 2024 08:16:21 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3654.120.0.1.15) 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:292236 Archived-At: 22 sep. 2024 kl. 16.12 skrev Stefan Monnier : > 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. I don't think an X11 client should ever claim CLIPBOARD ownership merely = for marking a selection, as opposed to issuing a 'Copy[ to clipboard]' = operation, but seem to recall that it did happen with some broken = clients. PRIMARY is indeed different and that's probably what confused = programmers back in the day, especially since old clients like Xterm = emphasised the use of PRIMARY. > 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). The O(N) cost in time and space is a problem. X11 convention is that = PRIMARY is available for as long as the selection is visibly marked in = the client. [ What happens if another client claims PRIMARY? The first (losing) = client typically has two choices: either remove the selection so that = the user sees that the selection is no more (the classic Xterm way), or = repaint it in a 'local-only' colour to show that it can still be used = for other purposes. ] > 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. Yes, we'd need some sort of current-selection-extent object. The = question is, what should its lifetime be? A. For as long as the selection is active B. Until buffer is modified C. Indefinitely, using absolute buffer offsets D. Indefinitely, using markers I'd suggest A because that's closest to X11 practice. B would be doable. = C and D are taking it too far and recovering a rectangle would be a = mess.