Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show all entries for matched modules in search #139

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jvoigtlaender
Copy link
Contributor

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.

@mgold
Copy link
Contributor

mgold commented Nov 29, 2015

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.

@jvoigtlaender
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants