Add tabs for search for better information access

[GuillaumeGomez]

A few screenshots:

r? @rust-lang/docs

cc @killercup @QuietMisdreavus

[QuietMisdreavus]

[00:04:01] tidy error: /checkout/src/librustdoc/html/static/main.js:896: line longer than 100 chars
[00:04:01] tidy error: /checkout/src/librustdoc/html/static/main.js:898: line longer than 100 chars
[00:04:01] some tidy checks failed

[GuillaumeGomez]

Arf, forgot tidy check once again...

[killercup]

Nice! This is a very nice step to making the search more accessible.

At RustFest, we talked a bit about what the search can already do, but one thing I didn't think of: Can you search for a function that has "foo" in its name that returns a usize? I'm not sure I have a good idea how to do the UI for this, but I guess the code itself might already support this in some capacity.

[killercup]

Nice! This is a very nice step to making the search more accessible.

At RustFest, we talked a bit about what the search can already do, but one thing I didn't think of: Can you search for a function that has "foo" in its name that returns a usize? I'm not sure I have a good idea how to do the UI for this, but I guess the code itself might already support this in some capacity.

[killercup]

Heh, that's such a negative way to write this ;) How about

obj && obj.type && obj.type.inputs && obj.type.inputs.length > 0

[GuillaumeGomez]

I wanted to avoid putting all my code in an if condition but either way is fine for me so let's go for it!

[killercup]

You replace the whole for thing with

return obj.type.inputs.some(function (x) { return x.name === name; })

but I'm not sure if we still need to support browsers which don't have Array.prototype.some.

[GuillaumeGomez]

That's the point. I'm supporting as much browsers as I can.

[killercup]

Maybe

As return value

for consistency?

[GuillaumeGomez]

Good point!

[killercup]

Maybe

As a parameter

[GuillaumeGomez]

You can look for multiple parameters at once (String, usize -> *).

[killercup]

Protip:

elems[2].onclick = function() { printTab(2); };

can be

elems[2].onclick = printTab.bind(null, 2)

[GuillaumeGomez]

I find it less readable. :-/

[GuillaumeGomez]

At RustFest, we talked a bit about what the search can already do, but one thing I didn't think of: Can you search for a function that has "foo" in its name that returns a usize? I'm not sure I have a good idea how to do the UI for this, but I guess the code itself might already support this in some capacity.

You can't do both at once. You can say that you're looking for a function called to_string:

fn: to_string

Or for a function which returns usize:

fn: -> usize

[QuietMisdreavus]

Forgive my ignorance of the JS part of rustdoc, but i think i'm missing something. What is obj.type here, and why does its presence keep it from getting into results['others']? Is that on purpose?

[GuillaumeGomez]

You can see everything as a hashmap in js, so obj.type == obj['type']. In this case, if there is no type (which is just a regular field, nothing particular), it means it's not a function nor a method so I put it in "others".

[QuietMisdreavus]

So is results['others'] not meant to be the same as the current search results? I'm concerned that you won't be able to find a function by name if it's not returning something with the same name. For example, are you able to find str::to_lowercase by searching for something like lowercase? Will you be able to find that method on any tab in your new layout?

[QuietMisdreavus]

Why is this condition not just results['others'].length < maxResults? I just checked out your PR and didn't see any difference between the longer form you have here and taking these extra conditions out. What is this trying to do?

[GuillaumeGomez]

In case the only thing(s ?) match are the arguments or the returned type, I don't want to add extra information. For me, the 'others' tab is also about the type/function/module's name so it seems logical to not add everything (even if the filter is pretty light).

[QuietMisdreavus]

After some checking, it seems like it won't stop things getting into results if their name matches as well as having a parameter type that matches (e.g. "Result" will show Try::into_result on both the "As return value" tab as well as the "Types/modules" tab) so i'll retract this concern.

[QuietMisdreavus]

@bors r+

I'm incredibly excited to see this land. I think it greatly helps discoverability in docs. It's not quite perfect (e.g. searches for io things won't get a lot of type-based results since they're all wrapped up in Results, but searching for Result doesn't return the mass of responses you would expect - in fact, it only returns places where Result was used with generic types, like on the Try trait, or on Option/Result combinators) but i'd like to get this landed and work on tweaking the search index in follow-up PRs.

cc #44024 since this helps that out

[bors]

📌 Commit 3a65d12 has been approved by QuietMisdreavus

[bors]

⌛️ Testing commit 3a65d12 with merge 8dcd0e1...

[bors]

💔 Test failed - status-travis

[kennytm]

@bors retry

• Android SDK HTTPS issue (fixed in #45193)

[bors]

⌛️ Testing commit 3a65d12 with merge d21c023...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: QuietMisdreavus
Pushing d21c023 to master...