package.elm-lang.org icon indicating copy to clipboard operation
package.elm-lang.org copied to clipboard

Show all entries for matched modules in search

Open jvoigtlaender opened this issue 9 years ago • 2 comments

As explained here, I think it makes more sense to present links for all subentries of a module that matches the search term on a package's page.

From over there:

Otherwise, the UI experience seems to become inconsistent. Right now, when I have put something into the search box, I know that I don't have to click on the module links, because anything that is relevant for my query will appear as links a level deeper. This expectation is broken if for "rand..." I do get the Random link, but not the Random.bool, Random.int etc. sub-links.

And I'd even go a bit further. Let's say I have seen Color.black mentioned somewhere, and want to find it. So on the core package page, I start typing "color.black" into the search box. (There is no reason for me really to know that I shouldn't do that. That I should only type "black", not "color.black" as I have seen mentioned somewhere.) The current behavior is that I never get to see the actual link to Color.black.

This PR fixes the behavior. For example, if I type "random" into the search box, I now get this: unbenannt instead of just the "Random" link.

I think this is preferable. If I know I'm looking for the docs of Random.generate, I want to be able to:

  • go to the core package, type "random" into the box, get a link to Random.generate I can click,

instead of:

  • go to the core package, type "random" into the box, get a lone link to Random that I have to click, to then go linearly through the Random module page to find generate somewhere in there.

jvoigtlaender avatar Nov 29 '15 15:11 jvoigtlaender

I'm worried that if you type graphics the search results will be overwhelming. However, if you type *List.map` it doesn't work, and probably should.

mgold avatar Nov 29 '15 18:11 mgold

Can we separate the discussion of what should happen with List.map out to another issue? I mentioned before that searching anything with a . does not currently work, and it does not work with my pull request here either, so it is clearly a separate thing to consider.

About the "graphics" case, yes, there will be many results. But that's because there is much stuff in Graphics (it's also a rare case, probably, because usually modules are smaller). Even so, I think it's good to get all those results. Consider the case that I am looking for a certain function, I know it's in Graphics somewhere, but I don't remember the exact name. I go to the core page, enter "graphics", see the results and recognize the wanted function immediately now that I see its name in the list. So I can click on it and am where I wanted to be. In contrast, with the current setup, I have no such discoverability option. I can only enter "graphics", then jump to the Graphics page, and scan it linearly in the hope to recognize the function I was after.

jvoigtlaender avatar Nov 29 '15 18:11 jvoigtlaender