young-developer/nppNavigateTo

NavigateTo causes NPP to freeze when a huge number of files would be shown

Closed this issue · 5 comments

Steps to replicate:

  1. Use the navigation form with the current file being at the top of a very large directory tree (say, 20k files or more)
  2. Enter a search term that is present in the name of every file in that tree (say, part of a common directory name)
  3. Watch the form and Notepad++ become unresponsive for a very long time

Proposed solutions/mitigations:

  1. The only complete solution to this problem would be to have the main form be on a background worker. I may try to implement this, but it may not be the best solution owing to the added complexity and possibility of concurrency bugs.
  2. Disable highlighting of matches if the number of results is over a certain threshold (say, 5000). This is very easy to implement, and will be part of a PR that I will submit shortly
  3. Add a timeout between keypresses and updates to the main form, to allow the user to type several characters before blocking input. After each keypress, wait a short time (say, 0.2 seconds). If any other keypresses happened during the timeout, do nothing. This does not completely eliminate the problems, but it helps address the potential frustration when, for example, a user wishes to enter the word "foobar" but they have to wait for each individual character to be processed. This may be rather difficult to implement, but I intend to work on it after addressing #55 .

@molsonkiko I think adding delay search will be more useful, something like that: https://stackoverflow.com/questions/12349810/delay-between-key-pressing-in-c-sharp

@young-developer
Awesome! Thanks for following up on this.` Haven't tested out the new release yet, but I'm interested to see it.

Out of curiosity, what aspects of my original implementation did you feel needed fixing, and what do you think is the advantage of the new approach?

@molsonkiko I used DispatcherTimer, Dispatcher and Task to run search.

IMO this issue is fixed as well as it's ever going to be, so I'm going to finally close this issue.