Combining "range selection" and "column selection" hang on large file

[whatbh]

Issue

I opened a moderately large file (1 MB), using solely "Shift selection" or "Alt selection" was smooth as usual, even when operated on the whole file. When I wanted to select a column by clicking on initial and final positions, I used Shift+Alt+select (i.e. combining "Shift selection" and "Alt selection"), it worked for a short range of rows (e.g. visible screen). But when I used Shift+Alt+select for a longer range of rows (e.g. the whole file), the program hung for a long time (that I had to terminate the process since I was not sure if it will eventually response).

One of the unique feature I love about ecode is its capability to quickly handle large files. This appears to be a bug. Please consider improving it.

Terminology

^{(Click to expand)}

**Range selection** (“Shift selection”): select initial position → hold Shift → select final position 【function: select everything between initial and final positions】 **Column selection** (“Alt selection”): select initial position → hold Alt → use Up/Down key to select the same column in adjacent rows 【function: select a column across multiple rows】 **Combining “Range selection” and “Column selection”** (Shift+Alt+select): select initial selection → hold Shift+Alt → select final position 【function: select a column across multiple rows between initial and final positions】

OS: Windows 11 Version: ecode 0.6.3

[SpartanJ]

Hi, thanks for the report! I can see this being tricky and problematic, since Shift+Alt+select and Alt+Up/Down do not expand the selection range but they create a new cursor for each line, if you select a whole range from a 1MB file you could be creating thousands of new cursors, I've never tried it but I would expect to find many slowdowns, I'm not sure if your specific use case could be improved much, I'll play around and try to find the most common issues (I can think a few from the top of my head), also I'm not sure if I should set an upper limit to the number of cursors that can be created (I'm pretty sure all editors do that, I just forgot to think about it), because at some point this is too heavy to handle gracefully. So in short: I'll play around and try to improve as many edge case possibles. One question: it was a plain text file or from some language? If you can specify the language it could be helpful.

 One of the unique feature I love about ecode is its capability to quickly handle large files. This appears to be a bug. Please consider improving it.

I'll do my best to improve the experience. Surprisingly currently ecode is quite fast with big files, much faster than many popular editors, so I'm happy with it, I usually open 50MB text files with word-wrap enabled and encounter zero problems, most editors struggle with that.

[whatbh]

Thank you for your continued efforts to improve your creation.

it was a plain text file or from some language?

I deal with .gro files. They are some sort of plain text files of tabular data. I regularly need to modify data in columnar fashion. For larger files I usually modify them in a programmatic way (e.g. python scripting), but for smaller files I found a text editor comes in handy. I have use Notepad++ in the past for these kinds of task. While the "Shift+Alt+select" in Notepad++ works a little different, it select the whole block of text, but it also create multiple cursors on a series of neighboring lines. They somehow managed to make selection (and cursor creation) like that nearly instant (for ~1 MB files), although subsequent modification of the selected text might be laggy, but it eventually resolves within a reasonable time frame.

I'm not sure how it is implemented; might be my use case is just an atypical situation, but I think there's still room for improvement.

[SpartanJ]

I just pushed an optimization for multi-cursor that improves the performance like 100x, can you test the nightly build and tell me if that's good enough for your case?

[whatbh]

It seems you're halfway there, detective. Joking aside, on my end, I can click on the initial position on a lower line, Alt+Shift, and then click on the final position on an upper line, then the selection works like a charm. But I can't do that if I click on an upper line first and then click on a lower line. Can you reproduce this on your end?

[SpartanJ]

haha I'm not able to reproduce it, it works the same way from both directions. What do you mean with "I can't do that if...", it does not create the cursors? it hangs? what exactly happens?

[whatbh]

It does not create any extra cursor except the first one at initial position, but the app does not hang. I can click on an upper line from that to create a column of cursor, but clicking on a lower line does not create anything.

[SpartanJ]

Ohh you're right, thanks! I just pushed a fix. Nightly build will be available +15m after this message.

[whatbh]

Yay. Fresh out the oven. The nightly build worked perfectly as expected. One minor thing is that, now, if I select the initial position in an upper line and click anywhere in a lower line ("Down" direction), it can create a series of cursor in single column (Figure 1). This is comfortable to have. But when I select the initial position in a lower line and then click an upper line at a different column ("Up" direction), it can end up creating multiple series of cursors (Figure 2).

Figure 1: "Down" direction. Clicking at different position still create cursors based on initial position.

Figure 2: "Up" direction. Clicking at different position create multiple series of cursors based on final position(s)

[SpartanJ]

I think that you have a point, I pushed a change that will always create new cursors in the first cursor column position. Is this what you expect? I actually don't have an strong opinion on how it should behave, so let's play around and see how it feels. vscode will generate a selection for each cursor, it tries to generate a filled rectangle of selection, I'm not sure if we should copy that behaviour, I'll think about it and also check other editors (I'm not a fan but maybe this is "standard").

Nightly should be ready in a few minutes, let me know what you think. Thanks!

Edit: Zed and Geany behave exactly like vscode. QtCreator tries to generate a rectangle but only during the first expansion of the multi-cursor selection, then stops creating cursors. Sublime Text and Kate does not seem to support this feature (or I cannot find it, kinda surprising if they don't).

[whatbh]

I should have said that I am ok with either logic for selection but I expect it to be consistent for both directions. So, I am happy with the latest nightly build. But yeah, I'm also not a fan of rectangular selection and prefer the current behavior. Thank you for all the hard work.

[SpartanJ]

Great! I'll keep it then. Thanks for the help!