feat: add setting for multi cursor limit

[SethFalco]

This PR fixes #81589

This adds a new setting called editor.multiCursorLimit.
Originally, the proposed name was editor.multiCursorMaxLines. However, I opted against as having multiple cursors has nothing to do with lines. (That was just their particular use-case, but there can be many cursors on the same line.)

Ref: #81589 (comment)

However, I also think this is a poor use-case, so I have still put in a hard limit of 100,000 cursors. (Maintainers are welcome to suggest otherwise, maybe 1,000,000 is a better max?)

With the following specs I can already make VSC stop responding when I try to create 88,000~ text cursors at once. (It doesn't crash entirely, though! Just takes 30~ seconds or so to type a character.)

OS: Debian 11 (Linux)
CPU: i7-11370H (8 threads)
RAM: 64 GB

Instead of limiting users to 10,000 cursors, we can limit them to 10,000 by default and encourage them to use Find and Replace instead for larger edits, still allowing them to increase this limit if they really want to. (The reality is, Find and Replace is a better tool for the job and can very likely be used in any case you're looking to modify 10,000+ lines in the same file anyway.)

I think this is a good compromise between giving users what they want, but also prodding them to use a more practical method that isn't going to kill their machines.

Screenshots

When the user hits the cursor limit.

The action buttons open the find and replace tool and editor.multiCursorLimit respectively.

The new setting:

Related

• Visual studio crashes for 735K cursors #28121 - The reason the 10k limit was put in the first place for context.

Potential UX Improvements

Notification when setting is already the max value

Currently, we show Open Settings regardless of what the value of the setting is. But doing "Open Settings" isn't going to do the user much good if they've already changed the setting to the hard-coded maximum value.

Is it worth doing/showing something different for users that have already set the setting to the max value?

Message

Maybe the notification should clarify that it's for performance?

The number of cursors has been limited to {} for performance. Consider using find and replace for larger changes.

---

PS: Only implemented this because it has a lot of demand and other code editors support more cursors.

[SethFalco]

Rebased and resolved merge conflicts!
Would still be great if GitHub could notify us when a PR gets conflicts after being open. ^-^'

Meanwhile, not sure if the tests are failing because of this PR. 🤔

/mnt/vss/_work/1/s/node_modules/gulp-remote-retry-src/index.js:70
                        error = new Error('Request ' + url + ' failed with status code:' + response.statusCode);
                                ^

Error: Request https://api.github.com/repos/microsoft/vscode-js-profile-visualizer/releases/tags/v1.0.3 failed with status code:403

Looks like CI got rate limited here? (Logs)

The smoke test I can evaluate, but doesn't seem related on the surface anyway. 🤔
I probably did something dumb for that one, I'll try figure out what's wrong.

[SethFalco]

Ahh, just rebasing it again and pushing resolved the failing tests at least! Should be all good now.

[hediet]

Please run compile again to fix the merge conflict. Thanks!

[SethFalco]

Rebased and re-requested reviews!

Sorry for the request spam, didn't realize clicking one and then the other would remove the previous request.

[hediet]

Thanks for solving the merge conflict! Please merge in future (rather than rebasing), as we don't have to review everything again then.

[RokeJulianLockhart]

Why did you merely increase the limit rather than remove it? I see no reason why a maximum value is necessary.

[SethFalco]

Why did you merely increase the limit rather than remove it? I see no reason why a maximum value is necessary.

Because VSC unfortunately becomes unstable when you try to have too many cursors. When or if that's addressed, it'd make more sense to remove the limit entirely, but for the moment it'd make for a worse UX if users can freely increase it to something that entirely crashes the program, and even worse, potentially result in loss of unsaved changes.

With this in mind, I think this is a good compromise and allows users to learn how to use Find and Replace.

i.e. to update the start of each line you can replace ^ (with regex enabled) with {your changes here}, rather than actually typing on > 100,000 lines.

If you disagree with this, feel free to open another issue/discussion with your use-case and this can be discussed with the maintainers and potentially changed. I am not against raising the limit further or removing it entirely, but I am wary of the consequences of it while the underlying performance issues haven't been addressed.

My goal in this PR was to direct users to find and replace, not to increase the cursor limit.