Enhanced search

[koppor]

I want to search for Files in the OpenJDK

I was assuming that if the full string matches a class name, that class was listed first.

Proposal:

• If full class name is hit, list htat class as first
• If possible: Support CapitalLetterSearch. FSP should match FileSystemProvider (IntelliJ feature ^^)

---

Context:

JabRef/jabref#12867 (comment)

I do not know the full package by heart and I do not want to look it up ^^

[Stewori]

Quick workaround: Files$ matches at the end only as regex syntax is supported.
(not saying this issue is invalid, I'll think about how to implement this enhancement)

[Stewori]

One rather simple tweak I just made is that if the search string contains at least one capital letter, the search is now case-sensitive. This readily narrows searches like for "Files" significantly. (reload page with ctrl-F5 to get the update applied quickly)

I admit that sorting better hits to the top would be nice, but it is not a trivial change. You probably noticed that the search results are organized hierarchically. Sorting might break the hierarchy and scatter the results. Also, it would mess up the code that currently organizes this hierarchy.
My idea is to sort just into two bins - priority matches and other matches. The priority matches would be displayed at the top, as one might guess. Within each category the hierarchy would be maintained. Priority matches are matches surrounded by word boundaries I suppose. However, this is not an easy change and I'll approach it together with other search-related todo's. There are more pressing issues ATM and I hope the case-sensitivity is sufficient in the mean time.

[Stewori]

FSP should match FileSystemProvider (IntelliJ feature ^^)

F S P (i.e. with blanks) does now do (almost) the same. It's case-sensitve due to presence of capital letters and blanks are interpreted as .* in APIdia's search ever since.
The intellyJ way would be to interpret any consecutive capital letters like FSP as F.*S.*P respectively...? (Okay, probably rather an [anything-non-capital] regex instead of .*, right?) Or only if the search text is all-capital? That would be easy to implement, but wouldn't it be too much magic? I'll consider it.

[Stewori]

Some update here: I really like the idea to support the IntelliJ style FSP-like search attempt. Given that it would be applied only if a capital letter is in the string, I guess it won't cause too much accidental surprises for users who just quickly type some letters: They usually type them lower case and the search would work as it always has.
The basic idea is to replace every capital letter, e.g. A by [a-z]*A. That would still allow to narrow down something like StringBuffer via StB to discriminate it e.g. from SequenceBuilder. The issue with this approach is that the search is advertised to support regex already and a simple search/replace to prepend [a-z]* before capital letters might interfere with other regex constructs the user has typed, e.g. special squences like \D or [AWT] or so. To sort this out, I prepared some code to guard

• letters preceded by \
• letters inside [...]
• letters inside (?<...>)

Getting this right (with simple methods) was a bit tricky, but I think I can roll out this feature rather soon.

[Stewori]

Okay, the change is now online (refresh with ctrl-F5 to force-reload the script). Some notes:
A search like FSP so far does not match accross . characters and does also match in the middle of a name, e.g.:

FSP finds FileSystemProvider, but also DateFormatSymbolsProvider and DecimalFormatSymbolsProvider. One can prepend ^ to force matching from the start: ^FSP omits the latter two. DFSP matches only the latter two and DaFSP matches only DateFormatSymbolsProvider.

SPA finds ScrollPaneAdjustable, but not ScrollPane.AccessibleAWTScrollPane. One can include the latter simply by inserting a space: SP A will match it.

[koppor]

Nice one!

Now, I think of manually selecting multipe projects - or ApiDia knows all dependencies:

Example for a Spring project_

My muscle memory tells me, that I can use lower case characters to refine the search:

[Stewori]

Refining the search with lowercase characters should readily work as expected.
Searching dependencies and perhaps an arbitrary selection of projects is a planned feature indeed, but it's not a simple enhancement. Given your request, I'll move it up on my priority list.

[koppor]

Related - I want to have the JavaDoc fro URI

Reason: I would like to review following code snippet:

I searched at the main search, where it says "Search for ... artifact" - and I was "artifact" interpreting freely ^^

[Stewori]

Yeah, the search on the landing page is only project level and "Artifact" refers to "Maven Artifact". The description should be more explicit I guess. So, to search for a class like "URI" you currently need to know in what project to search for. Indeed I do have plans for an enhanced search that can search for symbol names across various projects. The technical challenge is to realize this type of search within the current infrastructure. A major hidden strength of APIdia is that it runs with a very low server demand, which makes the hosting affordable. I think it's possible to retain this advantage while offering a cross-project symbol search, perhaps even a fulltext search, but it's not a no-brainer to get this right. Also, search results will have to be presented in a more structured way since vastly larger result sets have to be expected.
Including dependencies of a project into the search as you suggested earlier may still be a lower hanging fruit and a reasonable intermediate milestone.

Perhaps, the discussions area is a better place to talk about such bigger enhancements. There, someone already brought up a feature request to include a source view.

[Stewori]

you currently need to know in what project to search for

To make this easier to find, at least if the project you review is itself on APIdia, the doc pages list the imports of a particular class at the top. This info is not present in normal Javadoc, and I took care to include it precisely to make it easier to jump to dependencies of a particular class, especially to dependencies that are not visible on API declaration level but hidden in source code bodies.