I’d love to let JuliaHub host Gaston’s documentation, but since it’s a plotting package, it has a lot of examples (see Home · Gaston.jl) that, unfortunately, JuliaHub’s setup cannot reproduce.
Cool, thanks!
Most, maybe yes. But not all. Take for instance:
http://multivariatestatsjl.readthedocs.org/en/stable/index.html
Yeah I understand. What I said was more of a “I wish that it would be possible” than a feature request.
That’s a great feature! If I may add a few suggestions:
-
Once a search has been performed, the repository/package filter should automatically limit the entries shown to only those that contained matching results — see e.g. how grep.app behaves.
-
It would be nice to be able to group results by package rather than shown in a single flat list alongside the results from other packages. Even better if the group container could be collapsed to show only the header (package name) and a count of results.
-
Would it be possible to add syntax highlighting to the snippets of code in the results? And maybe also emphasis (e.g. yellow background) to the match within the snippet.
I don’t really get how package ranking works in the search page. E.g. searching for “tar” shows “Tar.jl” on second position (first is “Taro.jl”), and all other packages from pages 1 and 2 don’t have “tar” in the name at all. Then on page 3 there are “Tar_jll” and finally “TarIterators” that is actually relevant. Same with other searches.
The current algorithm doesn’t penalize single character transposes, which is why packages with tra
in their name are ranked highly. Fix is going to be out soon.
Quality search is a hard problem—it requires lots of user feedback to hone it to the point where it’s really good. This is why JuliaHub is “in beta” and why we need this kind of feedback from users! Please keep posting bad cases, ideally as issues.
One way to improve search (may be not the best and may be already implemented) is to log user activity, where start is the search term and action is a click on this or that package. This way one can build relation between actual and expected position. Such a system can work without active user feedback and be more and more efficient as time goes, because it will have more and more data. And you can even backtest new algorithms on historical data.
Should I open issues for the three suggestions I offered above?
Please do!
Compared to the current Documenter.jl local search index and search, the JuliaHub search is much faster, and won’t require downloading the entire search index.
Would it be possible to in the future hook up this search to https://docs.julialang.org/, to improve the search experience? Or perhaps even make it an option in Documenter.jl?
There has been some prior work towards hosted search using Algolia, see RFC: Improved Search for Documentation and https://github.com/JuliaDocs/Documenter.jl/pull/976. But if a hosted search focused on Julia already exists, perhaps that can be used?
That’s a good idea. We could either redirect search to JuliaHub or use its search tech on docs.julialang.org with “powered by JuliaHub” branding.