all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	Eli Zaretskii <eliz@gnu.org>,
	72830@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#72830: Big rectangular selections are slow
Date: Sun, 22 Sep 2024 10:12:44 -0400	[thread overview]
Message-ID: <jwvwmj36b6r.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <5F6C5DCE-88F0-446D-8CBD-5E9EE26FFFC6@gmail.com> ("Mattias Engdegård"'s message of "Sun, 22 Sep 2024 15:27:50 +0200")

>>> - `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.






  reply	other threads:[~2024-09-22 14:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27 12:39 bug#72830: Big rectangular selections are slow Mattias Engdegård
2024-08-27 13:48 ` Eli Zaretskii
2024-08-27 14:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-27 16:42   ` Mattias Engdegård
2024-08-27 17:47     ` Eli Zaretskii
2024-08-27 19:16       ` Eli Zaretskii
2024-08-27 18:23     ` Juri Linkov
2024-08-27 18:55       ` Drew Adams via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-27 19:03       ` Eli Zaretskii
2024-08-27 19:44     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-29  3:56       ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-29 10:22         ` Mattias Engdegård
2024-08-29 11:18           ` Mattias Engdegård
2024-08-29  8:09       ` Mattias Engdegård
2024-08-29 20:04         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-30 15:20           ` Mattias Engdegård
2024-09-20 12:53             ` Mattias Engdegård
2024-09-21  2:07               ` Stefan Kangas
2024-09-21  8:26                 ` Eli Zaretskii
2024-09-21  3:05               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-22 13:27                 ` Mattias Engdegård
2024-09-22 14:12                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-09-22 15:16                     ` Mattias Engdegård
2024-09-22 15:32                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-22 16:22                         ` Mattias Engdegård
2024-09-22 17:37                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-23 10:42                             ` Mattias Engdegård
2024-08-29  0:45     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-29  3:39       ` Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-29  4:44         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-29  0:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvwmj36b6r.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=72830@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=juri@linkov.net \
    --cc=mattias.engdegard@gmail.com \
    --cc=michael_heerdegen@web.de \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.