It would be really useful if
doc.rust-lang.org had some kind of API that returned OpenSearch-compatible
application/x-suggestions+json. Such a change would allow autocomplete suggestions when you activate that search engine in a browser URL bar.
What would the work involved with such a change look like? Is this something I could help with working on?
This was discussed a little on Discord. Some points that were brought up:
I'd like to hear more about your use case - what do you want this for?
I make fairly heavy use of Firefox's domain-specific search engines, and I imagine many others do as well.
Integrating with the browser suggestion feature would be very convenient in allowing previews of crate names and functions before the search is completed.
As for the XML point: I haven't looked into this much, but I believe this is just the manifest which provides the "Add Search Engine" menu option. I believe it would be fairly straightforward to host this statically.
The main interesting bit as I see it is the API that would be called to populate the suggestions.
@CodeSpelunker if you want to search in Rust docs from your url bar you have these options:
1) the rust firefox add-on: https://addons.mozilla.org/de/firefox/addon/rust-search-extension
!bang syntax from duckduckgo :
3) roll your own search OpenDocument XML: https://apiraino.github.io/firefox-custom-search :-)
if it's as simple as hosting the static manifest, that seems fine to me
yeah, it's a simple XML file and then add it to a
<link.... in the headers of the website
@apiraino want to make a PR for that? :wink:
I can open a PR it you want
oh right you got me :D
@apiraino, this looks very useful, and might even obviate what I'm talking about.
@Joshua Nelson, I believe the XML defines a few things, which FF/Chrome parses to register the search engine. Among that metadata is the search engine name, the standard search API (like when you just press Enter or select a suggestion), and the suggestions API returning
and the suggestions API returning application/x-suggestions+json.
How would that work for a static server?
That's what I'm not so sure about.
I'd also like to look a little more closely at how the extension @apiraino had linked works. It might be doing something differently than the other search engines I've seen.
I don't know enough about service workers and lambda to give you a good answer on how that would be implemented in this case
If anyone else is interesting in looking through that extension's source code: https://github.com/huhu/rust-search-extension
@apiraino This extension won't work for me.
There is no way to customize the prefix shortcut through the Settings interface, and the suggestions get mangled with my default search engine (Google) settings. Underneath the extension results, I also get Google autocomplete results for
So, back to square one here.
To be noted, it has to be done on
doc.rust-lang.org side and not in rustdoc
and I don't know how it works there...
the suggestions get mangled with my default search engine (Google) settings. Underneath the extension results, I also get Google autocomplete results for
@CodeSpelunker what a drag. But thanks for reporting on that
To be noted, it has to be done on
doc.rust-lang.orgside and not in rustdoc
didnt look yet at the codebase , you mean the patch should be pushed here or not here?
I see. I thought this file here really had the header I was looking for
I'm unclear what you're looking for.
I don't know how this can work as a static file.
hmm ok I'll check later a bit the code and be back with a bit more context. I'm thinking two things that may be both wrong:
doc.rust-lang.org is an artifact of compiling librustdoc (that html directory)
2) when I compile my crate I use the same static HTML+css assets as doc.rust-lang.org
yes, that's all right, but I don't know how you can do opensearch with static files
oh wait you were asking specifically about the header
sorry, that's the right place for the header
and then add another static asset (the XML file)
that would probably be in
I guess I'll see in the PR, but I don't think adding yet another file for such a specific feature is worth it for rustdoc
But if the file is always the same and is rather small, then I guess it's fine, even though I think it's too much
@GuillaumeGomez for this feature to work it is mandatory to have a 10-ish lines XML similar to what docs.rs already has
and add a
<link... header to the HTML
No way around this (afaik). I perfectly understand you want to avoid bloat so it will be fine if you don't want to merge :thumbs_up:
So just like I said: it seems better to put it into doc.rust-lang.org instead
I don't see why users generating doc locally should care about that
Last updated: Oct 11 2021 at 22:34 UTC