Add some indication on top and bottom that there are addtional cursors not in the view.

[dpc]

Many time's already I've been beaten by accidentally having multiple selections that I wasn't aware of, and messing the whole file up. I think there should be some very clear and visually laud indication that there are more selection than currently seen.

[mawww]

Thats a good idea, I am not sure however what to display/where. We do have the selection count in the status line that already give this information but is not very "visually laud", a possiblity would be to change its face to something more attention-grabbing whenever we have not-displayed selections.

[Screwtapello]

Strawman idea: when there are cursors above the top of the viewport, draw a band across the top line in the secondary selection colour saying ↑↑↑ More cursors above ↑↑↑. When there are cursors below the viewport, draw a band across the bottom line saying ↓↓↓ More cursors below ↓↓↓

[eraserhd]

I hit this a few times a week, but I can only think of one instance where it was impossible to fit all the selections on the screen by moving the viewport. I think a few heuristics could make this almost never happen for me:

• Never scroll lines off the client if the client is longer than the file (and never scroll off more lines if it would leave blank lines on the screen).
• Attempt to scroll the viewport to keep all selections in it during s and friends.

(Also, it would be nice to not move the viewport when using <count>g if the line is already on the screen.)

All that said, I do like "more cursors above" and "more cursors below" with arrows, although they are technically "selections".

[dpc]

I was thinking around same lines as @Screwtapello . Maybe not More cursors below, but eg. squash all selections above into one line, and display that the first line in some distinct way. Similarly for everything below on the last visible line. This has a benefit of giving more information on how do other selections actually look, which might be sometimes useful.

[mawww]

I think I would prefer to avoid allocating two full display lines to show this information...

I am dubious that we really need to know if the invisible selections are above or below the screen, in both cases rotating the main selection will jump to one of them. I be more in favor of displaying that information in the status line, but in a pretty obvious way (maybe a centered "offscreen selections" text in info face would be enough).

[dpc]

Anything works, but you don't need to allocate anything. One would still see whatever was on the first and last line, it just there would be some characters with different background color, indicating selections out of the current view.

[Screwtapello]

I can only think of one instance where it was impossible to fit all the selections on the screen by moving the viewport.

This happens to me fairly regularly when I'm refactoring and I have a huge suite of unit-tests that need updating. I do %s and find the functions that need to be changed. Quite often it's in setup code that appears with minor differences inside a bunch of tests, so the first and last matches can be quite far apart.

squash all selections above into one line, and display that the first line in some distinct way. Similarly for everything below on the last visible line.

I'd probably have to see this in action to comment on it, but I worry that it might not be obvious that the selections are above the top of the window, rather than at the top of the window.

I am dubious that we really need to know if the invisible selections are above or below the screen, in both cases rotating the main selection will jump to one of them.

When I jump between search results with n, and go past the last match, I get a warning at the bottom of the screen to tell me I've looped back around to the beginning. When I jump between search results with ) there's no such warning.

When I'm working with multiple cursors, I often want to cycle through all the matches to double-check I'm not breaking one location while I'm fixing others. When all the matches are in similar pieces of code (like unit tests, see above), it can be hard to tell if I've cycled far enough, or too far. Having separate "above" and "below" markers solves both the "have I cycled too far" and the "I forgot I had multiple cursors active" problems at once.

(yes, the "have I cycled too far" problem could also be solved by making it print a message to the status line)

[occivink]

When I jump between search results with ) there's no such warning

it can be hard to tell if I've cycled far enough, or too far

For what it's worth these kind of issues (which I also encounter) would be reduced by having a scrollbar. It would also be possible to show offscreen selections via scrollbar markers so that they're less surprising

[lenormf]

I think you already have information that you have multiple selections, in the modeline, it says how many you have exactly.

[Screwtapello]

There's already an indication, but in dark-blue-on-black (at least in the default colour scheme) I don't think it counts as "visually loud".

[alexherbo2]

@occivink Like when we search in Chrome?

[mawww]

@Screwtapello my initial suggestion was to change that face to something more "loud" when some selections are offscreen.

[dpc]

I just ruined a couple hours of work, again, because of this pitfall, so decided to check on this issue again. 😆

I don't know about your setups, but I sometimes work on huge screens etc. If I am to notice this notification at the right side of status bar, at the very bottom of the screen it has to be really "loud": like animated locomotive kind of "loud". When I'm coding I look mostly at the area where the cursor is (if even looking at the screen, sometimes). I would consider disabling statusbar, and would not miss it at all. :)