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. :laughing:

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. :)

[mawww]

I guess the loudest I can think of is to make something blinking. I agree this is an issue worth fixing, I just dont have any satisfying solution for it. According to what you said, seems putting something on first/last line would not work as it might be too far away from the cursor. We could use an info box for that, it would be pretty loud (perhaps too much ?).

[dpc]

I think blinking would do - it would be hard not to notice. I mean - if it's going to be a "loud" blinking. So :+1: from me.

According to what you said, seems putting something on first/last line would not work as it might be too far away from the cursor.

Yeah. It would still have to be quite visually distinct. Something that makes a bit better (I think) than status line is that when scrolling buffer view, it would stay fixed which effectively makes it a movement over the content being scrolled, which is quite easy to notice. Also usually it would be on both sides, though it's not guaranteed. And it is not "always there" like status line, but "pops-up". The problem with status bar is that it is always there, kind of changing, but typically not in a very interesting way, and is just a noisy, but fixed.

[eraserhd]

I keep thinking it would be neat if Kakoune could “elipsize” or fold unselected parts of the buffer in order to fit more selections on the screen. Now I’m wondering whether doing so might fix this problem, too, because the screen would have to be full of selections for there to be selections off the screen.

Hrmm

On Thu, May 30, 2019 at 2:57 AM Dawid Ciężarkiewicz < notifications@github.com> wrote:

I think blinking would do - it would be hard not to notice. So 👍 from me.

According to what you said, seems putting something on first/last line would not work as it might be too far away from the cursor.

Yeah. It would still have to be quite visually distinct. Something that makes a bit better (I think) than status line is that when scrolling buffer view, it would stay fixed which effectively makes it a movement over the content being scrolled, which is quite easy to notice. Also usually it would be on both sides, though it's not guaranteed. And it is not "always there" like status line, but "pops-up". The problem with status bar is that it is always there, kind of changing, but typically not in a very interesting way, and is just a noisy, but fixed.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/mawww/kakoune/issues/2727?email_source=notifications&email_token=AABD6VGHANIPPWIJLV55FVLPX53D3A5CNFSM4GUZRQQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWRRIMY#issuecomment-497226803, or mute the thread https://github.com/notifications/unsubscribe-auth/AABD6VFKYEDPJ5WP45L5TQ3PX53D3ANCNFSM4GUZRQQA .

[Delapouite]

The VSCode Dance plugin, which is trying to bring the Kakoune niceties to this editor, recently implemented such a feature:

On the screenshot above, I opened the commands.cc file, selected the complete buffer and then sCommand<ret> to create selections for all the "Command" occurrences.

On the bottom right, in the status bar, we can see that it generated 245 selections, so obviously many of them are out-screen. The two orange bars at the top and bottom of the editor serve as visible indicators that "hidden" selections are there and so act as a welcomed warning to remember to clear the selections after a specific editing operations has been done.

Bonus point: the scrollbar also offers some insight on the placements of selections.

[Screwtapello]

Right now I'm using (a slightly modified version of) the scrollbar.kak plugin, which draws a scrollbar in a line-specs highlighter. I also opened commands.cc, typed %sCommand<ret> and here's what I wound up with:

In my current configuration, the black-background portion of the scrollbar (about a third of the way down the left-hand edge) represents the current view, while the grey-background portion represents the entire buffer height. Within those areas, each character represents the number of selections in that portion of the buffer - ⢿ represents 7 selections, ∴ represents 3 selections, and ▒ represents "more selections than can be drawn in a single character". Selections inside the visible portion of the buffer are displayed in dark-grey to avoid being distracting, while selections outside the visible portion are displayed in yellow to be as distracting as possible.

This is not as eye-catching as the orange bars at the top and bottom of Delapouite's screenshot, and not as detailed as the selection-markers in VSCode's scrollbar, but given the limitations of terminal display, I'm quite pleased.

[eko234]

Hi, what about something subtle, like using some configurable variables in the status line that would be by default two ascii triangles pointing up and down, denoting where are those extra pesky selections, and maybe denote with color of text the more than one condition.