[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#72830: Big rectangular selections are slow
From: |
Mattias Engdegård |
Subject: |
bug#72830: Big rectangular selections are slow |
Date: |
Mon, 23 Sep 2024 12:42:06 +0200 |
22 sep. 2024 kl. 19.37 skrev Stefan Monnier <monnier@iro.umontreal.ca>:
>
>> Sorry if I've lost track with your step numbering, but the problem is still
>> that we extract and retain the selected text both at selection and each
>> incremental modification of it.
>
> "incremental modification" is my step 2. And in the design, step
> 2 should not actually compute the content of the selection.
> IOW, what you describe sounds like a plain bug.
No argument there!
> Modifications deactivate the selection, so if we want to preserve the
> selection until after modifications, that's when step 4 comes into play.
Yes, let's not do that then.
(I'm not sure if it's even possible to delay the text extraction of PRIMARY
until it is actually requested on macOS, where PRIMARY and SECONDARY are just
alternative pasteboards. I think the idea is to cooperate with XQuartz, but it
should be safe to have that feature disabled by default.)
- bug#72830: Big rectangular selections are slow, Mattias Engdegård, 2024/09/20
- bug#72830: Big rectangular selections are slow, Stefan Kangas, 2024/09/20
- bug#72830: Big rectangular selections are slow, Stefan Monnier, 2024/09/20
- bug#72830: Big rectangular selections are slow, Mattias Engdegård, 2024/09/22
- bug#72830: Big rectangular selections are slow, Stefan Monnier, 2024/09/22
- bug#72830: Big rectangular selections are slow, Mattias Engdegård, 2024/09/22
- bug#72830: Big rectangular selections are slow, Stefan Monnier, 2024/09/22
- bug#72830: Big rectangular selections are slow, Mattias Engdegård, 2024/09/22
- bug#72830: Big rectangular selections are slow, Stefan Monnier, 2024/09/22
- bug#72830: Big rectangular selections are slow,
Mattias Engdegård <=