Community
Participate
Working Groups
The first results of Quick Text Search should be visible directly in "Find Actions"
New Gerrit change created: https://git.eclipse.org/r/150844
Gerrit change https://git.eclipse.org/r/150010 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=4252e53c7d5373092cacd6128d39cea35618b21e
Gerrit change https://git.eclipse.org/r/150844 was merged to [master]. Commit: http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/?id=2c2308f00654382c5132b1550bb5b3f071822862
(In reply to Eclipse Genie from comment #3) > Gerrit change https://git.eclipse.org/r/150844 was merged to [master]. > Commit: > http://git.eclipse.org/c/www.eclipse.org/eclipse/news.git/commit/ > ?id=2c2308f00654382c5132b1550bb5b3f071822862 I get this error : Error Line 67, Column 13: document type does not allow element "ul" here; missing one of "object", "applet", "map", "iframe", "button", "ins", "del" start-tag <ul> No bug number also added in the entry.
Created attachment 280594 [details] partial threaddump Quick access has degraded severely in my large workspace. Opening quick access and typing "target" spawns a couple of quick search jobs (for "tar", "targ", etc.), and the list isn't filtered anymore until those are completed. The jobs for shorter strings get canceled, but that seems to be ignored by the job (thread dump extract attached). It takes nearly a minute until the expected target platform preference item is focused. Given my workspace size, I don't expect the quick search to be anything but slow so that in itself is not an issue. But it must not block other proposals/filtering. For now I've added "src" to the quick search exclusion list or is there another option to disable it completely? Version: 2019-12 (4.14) Build id: I20191107-1800 Not sure why I didn't notice that before.
The hotspot seems to be DefaultPriorityFunction::computeIgnoredFolders: //TODO: Hopefully this won't take too long to compute. Otherwise we may need to look at ways of caching it. // it probably doesn't change that often. IWorkspaceRoot::findContainersForLocationURI is unbearably slow on a workspace with many projects.
(In reply to Julian Honnen from comment #6) > IWorkspaceRoot::findContainersForLocationURI is unbearably slow on a > workspace with many projects. This should never be used in Quick Access, it has n^3 or worse complexity. If there are no alternatives (I haven't checked the code), I would propose to revert last change.
New Gerrit change created: https://git.eclipse.org/r/152466
(In reply to Andrey Loskutov from comment #7) > This should never be used in Quick Access, it has n^3 or worse complexity. Can it be documented in the Javadoc that this is a n^3 operation to avoid in case responsiveness matters? > If there are no alternatives (I haven't checked the code), I would propose > to revert last change. There is a timeout of 3 seconds for the QuickSearchQuickAccessComputer, I suggest we simply drop it to 200ms. In a near-ish future, the timeout would be controlled by QuickAccess itself (there is a ProgressMonitor already passed to computers to achieve that, it's just not much used so far).
Gerrit change https://git.eclipse.org/r/152466 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=f287323df9eee66578972d2fe839c1967723855b
@Mickael, Regarding the N&N Entry for "Find Actions finds text in file contents" I could not find the "Find Actions" listing the matching texts from files in Build id: I20191118-0600 ?
(In reply to Sarika Sinha from comment #11) > @Mickael, > Regarding the N&N Entry for "Find Actions finds text in file contents" > > I could not find the "Find Actions" listing the matching texts from files in > Build id: I20191118-0600 ? Did you see, in the N&N, the potential explanation of the cause """ If the Quick Text Search bundle wasn't started yet, you may miss those matches. In this case, you can ask directly Find Actions to activate the Quick Text Search by looking for a Activate bundle for 'File Content' proposals entry. """
(In reply to Mickael Istria from comment #12) > (In reply to Sarika Sinha from comment #11) > > @Mickael, > > Regarding the N&N Entry for "Find Actions finds text in file contents" > > > > I could not find the "Find Actions" listing the matching texts from files in > > Build id: I20191118-0600 ? > > Did you see, in the N&N, the potential explanation of the cause > """ > If the Quick Text Search bundle wasn't started yet, you may miss those > matches. In this case, you can ask directly Find Actions to activate the > Quick Text Search by looking for a Activate bundle for 'File Content' > proposals entry. > """ Yes, my mistake. I missed the text between two images. Not sure about others but If the sentence could start with "If you don't see those matches.." would have helped me. It's cool that we have added the step to activate the proposal from the dialog itself.
(In reply to Mickael Istria from comment #12) > """ > If the Quick Text Search bundle wasn't started yet, you may miss those > matches. In this case, you can ask directly Find Actions to activate the > Quick Text Search by looking for a Activate bundle for 'File Content' > proposals entry. > """ This is not practical. I've filed bug to 560415 fix this.
(In reply to Mickael Istria from comment #12) > """ > If the Quick Text Search bundle wasn't started yet, you may miss those > matches. In this case, you can ask directly Find Actions to activate the > Quick Text Search by looking for a Activate bundle for 'File Content' > proposals entry. > """ This is not practical. I've filed bug 560415 to fix this.
