Add search for external crates

[GuillaumeGomez]

In gtk-rs, a lot of crates are provided and have been split into 3 repositories: core, gtk3 and gtk4. Both gtk3 and gtk4 link to core using --extern-html-root-url, however it doesn't allow to look for items in core from neither of them.

The idea would be to query the search-index.js file from rustdoc front-end. However it brings the potential following issues:

• The file could not be found.
• It forces us to refresh the crate search filter (because we have new ones).
• It allows to load an unknown JS file and hope for the best (which is problematic in term of security).

Another option could be to simply generate the search index for those crates and use the --extern-html-root-url option to allow to go to the item from the search result. It would force us to add an option to only generate a search index for a crate and not its documentation though.

Out of the two appraoches, I think the second option is better.

However, do we want such a feature? Would it be useful to enough users to make this development/maintenance "worth it"? What do you think @rust-lang/rustdoc ?

cc @sdroege

[Manishearth]

The idea would be to query the search-index.js file from rustdoc front-end

I don't quite understand what's being proposed in this one: are you proposing we try and find the file on disk somehow?

Another option could be to simply generate the search index for those crates and use the --extern-html-root-url option to allow to go to the item from the search result

I also don't understand what is being proposed here.

[GuillaumeGomez]

Let me try to improve the explanations then:

In case you only document your current crate and not its dependencies, in the doc pages, if you use --extern-html-root-url it'll link to the correct page if you click on a type from one of the dependencies. However, you can't "search" for this type because it's not in the search index. It was brought to my attention that it could be useful to have the possibility to look for a type in a dependency that is available somewhere else.

Does it make more sense? If so I'll update the first comment.

[Manishearth]

Ah, so this is about cases where the entire deptree isn't being documented. This would probably affect docs.rs too (cc @jyn514)

I still don't quite get the solutions being proposed though.

[jyn514]

cc rust-lang/docs.rs#494

[Nemo157]

IMO this would have to be at least opt-in, as it would expose implementation details about facade-style crate-trees.

[GuillaumeGomez]

@Nemo157: I think so too. :)

@Manishearth: It's mostly about either we merge search indexes (with a little tweak in the externals URLs) when generating docs and trying to get external search index from a remote location.

[Manishearth]

It's mostly about either we merge search indexes (with a little tweak in the externals URLs) when generating docs and trying to get external search index from a remote location.

Right, I'm unclear as to how you're proposing it

[GuillaumeGomez]

Simply because I'm unclear about it as well. For the first case, I was thinking about adding an option to rustdoc to only generate the search index, but that would require to also use the --extern-html-root-url into account when generating docs for the crate (for the items from the external crates in the search index).

[Manishearth]

Right, you've proposed two solutions for it and haven't picked one yet, but I don't understand what those solutions are.