large selection behavior changed?

TBugReporter

I recently noticed something which I think is a change from older versions, or else I’m misremembering. If I’m working with a large file, trying to select a large portion of it, I think I used to be able to hold down Shift plus an arrow or PgDn or whatever, and stop when I got to the other end, but now the screen stops refreshing (other than the line count at the bottom) until I let go. Now I have to hold them a while, let go, figure out where I am relative to where I want to be, hold some more, etc. Frustrating.

PeterJones

@TBugReporter said in large selection behavior changed?:

I think I used to be able to hold down Shift plus an arrow or PgDn or whatever, and stop when I got to the other end, but now the screen stops refreshing

I don’t use “large” files, so I haven’t noticed any such behavior. Maybe it’s pure N++'s fault. Maybe it’s another plugin that’s slowing down your refresh, and you should try disabling plugins until it improves to find the culprit. Maybe it’s syntax highlighting and you need to do the Performance config settings to get it to not syntax highlight for large files.

However, some thoughts for potential workarounds:

Click (and release) to set the caret at the start of the section you want to select., then grab scrollbar (or mouse scrollwheel), and scroll until you see “end” you’re looking for, then shift-click to end the selection. This means that it doesn’t have to do all the selection updates for every line or pageful, and can instead just create the selection all at once.
If you can make a regex to define the beginning and end, then use FIND dialog and FIND NEXT action to select the first match, which will give you the selection.
If you can make a regex to define the end, but not the beginning, then put the caret/cursor at the beginning, search for (?s).*end (where end is your regex to define the end of the chunk), and turn off Wrap around so that the search will start where your caret/cursor is, and select everything until it matches the end regex.

Coises

@TBugReporter said in large selection behavior changed?:

I recently noticed something which I think is a change from older versions, or else I’m misremembering. If I’m working with a large file, trying to select a large portion of it, I think I used to be able to hold down Shift plus an arrow or PgDn or whatever, and stop when I got to the other end, but now the screen stops refreshing (other than the line count at the bottom) until I let go. Now I have to hold them a while, let go, figure out where I am relative to where I want to be, hold some more, etc. Frustrating.

I just tested with a file with 119,172,867 bytes in 19,437 lines. I saw what I think is the same behavior you are describing beginning at around 1000 lines. It didn’t stop updating, but got sluggish, updating less frequently, until around 2000 lines it effectively stopped updating at all.

I saw the same behavior in both 8.5.8 and in 8.6.9.

I found that I do not need to let up the Shift key to get the screen to update. If I hold the Shift key and repeatedly tap the arrow or Page Down key, rather than letting it auto-repeat, the screen updates with every tap.

My guess is that this is a Scintilla behavior, but I don’t know that for certain. It might be dependent on timing (Scintilla skipping screen updates when it gets a new update before it has finished processing the last one), which in turn might make it dependent on plugins (since they can slow the processing of messages). I did not try removing plugins to check.

TBugReporter

@Coises said in large selection behavior changed?:

119,172,867 bytes in 19,437 lines

Mine are similar in total size, but broken into around 3 million lines.

I found that I do not need to let up the Shift key to get the screen to update. If I hold the Shift key and repeatedly tap the arrow or Page Down key, rather than letting it auto-repeat, the screen updates with every tap.

Same here, but repeated tapping still takes too long (IMO) to complete the selection. My current workaround (after searching for alternatives) uses “Begin/End Select”. I just have to retrain my brain for this - it’s not as intuitive for me.

I did not try removing plugins to check.

Neither did I. It hadn’t occurred to me that that was a possibility.

mkupper

@TBugReporter It may also be an issue that is happening this week. The second Tuesday of a month is Microsoft’s “Update Tuesday”. Microsoft’s update process will lock the c: file system, do a bunch of stuff, and then unlock for a moment.

My desktop is getting clobbered and it’s particularly noticeable when dealing with large files in Notepad++. For example, today Notepad++ performance is sluggish but usable for normal size files. I opened a 175 mb (3 million line) file in Notepad++. Ctrl+End to get to the bottom of the file hung Notepad++ for about a minute. Now when I switch to another tab for a normal file it snaps over to the new tab. I switch back to the large file and it hangs for eight or nine seconds before it shows me the tab.

It does seem like Notepad++ and/or Scintilla does an unusual amount of something to figure out what needs to get painted when the view window is at the bottom of a large file. I ran a profiler but there’s next to zero disk I/O from Notepad++ when switching tabs. It checks the files on-disk size and time stamps as part of switching but that operation took 13 microseconds. Without a bunch of time consuming digging, I have no idea why Notepad++ is stalling for eight or nine seconds.

I did verify that it’s the scroll window being at the bottom of the file and not the caret position. I also saw that Notepad++ hangs with seemingly zero system calls and then after eight or nine seconds there is that 13 microsecond burst of activity.

I suspect the machine will get back to its normal speedy self once the Windows updates plus Microsoft Defender stuff is done.