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

Make docs search results URL-addressable #11760

Merged
merged 1 commit into from
Jan 24, 2014

Conversation

dmac
Copy link
Contributor

@dmac dmac commented Jan 23, 2014

This change adds two improvements to docs searching functionality.

First, search results will immediately be displayed when a ?search=searchterm
query string parameter is provided to any docs url.

Second, search results are now inserted into the browser history, allowing for
easier navigation between search results and docs pages.

@alexcrichton
Copy link
Member

This is pretty awesome!

It's been awhile since I've used web js stuff, but is history a well-supported thing by this point? Last time I used it I think I remembered having to conditionalize it based on the browser, but then again the last time I used it was like 4 years ago.

@adrientetar
Copy link
Contributor

This is awesome! 🌟

@adrientetar
Copy link
Contributor

@alexcrichton This might be of help: http://html5please.com/#history
Fallback: http://stackoverflow.com/a/9446306

Side note: we don't support polyfill for HTML5 elements so we're requesting a fairly recent browser already.

@alexcrichton
Copy link
Member

polyfill? I was unaware of that?

It sounds like history may not be ready for full-out usage though, so could you add a if window.history && history.pushState condition to dealing with the history state?

@adrientetar
Copy link
Contributor

@alexcrichton HTML5shiv is an HTML5 polyfill for IE up to version 8.

I'm not fan of using that kind of thing through, right now we display for IE up to 8:

This old browser is unsupported and will most likely display funky things.

...which will encourage people to upgrade their browser instead of staying with an old and dodgy thing being a pain for web devs.

@alexcrichton
Copy link
Member

I'm getting lost here, I have no idea what polyfill is?

I'm just thinking that if you have a slightly older browser it'd be better to be able to still search, right? Should we not have an if-check around dealing with the history state?

This change adds two improvements to docs searching functionality.

First, search results will immediately be displayed when a ?search=searchterm
query string parameter is provided to any docs url.

Second, search results are now inserted into the browser history, allowing for
easier navigation between search results and docs pages.
@adrientetar
Copy link
Contributor

@alexcrichton I agree that we should have that check.

I was just saying that generally we already require a fairly recent browser supporting HTML5 to display the page itself (that being said, js.history support remains unclear right now).
A polyfill is just a JS script that mimics a functionality on older browsers (for example, HTML5shim makes blocks like <header>, <section> or <footer> render on old IE).

@dmac
Copy link
Contributor Author

dmac commented Jan 23, 2014

Yes, checking for the history API is quite easy; I've added that gate. Note that it only gates the second improvement; the first improvement (searching directly from a URL with ?search=searchterm) is still available for all.

@kud1ing
Copy link

kud1ing commented Jan 24, 2014

bors added a commit that referenced this pull request Jan 24, 2014
This change adds two improvements to docs searching functionality.

First, search results will immediately be displayed when a ?search=searchterm
query string parameter is provided to any docs url.

Second, search results are now inserted into the browser history, allowing for
easier navigation between search results and docs pages.
@bors bors closed this Jan 24, 2014
@bors bors merged commit b869f36 into rust-lang:master Jan 24, 2014
flip1995 pushed a commit to flip1995/rust that referenced this pull request Nov 16, 2023
Don't check for late-bound vars, check for escaping bound vars

Fixes an assertion that didn't make sense. Many valid and well-formed types *have* late-bound vars (e.g. `for<'a> fn(&'a ())`), they just must not have *escaping* late-bound vars in order to be normalized correctly.

Addresses rust-lang/rust-clippy#11230, cc `@jyn514` and `@matthiaskrgr`

changelog: don't check for late-bound vars, check for escaping bound vars. Addresses rust-lang/rust-clippy#11230
flip1995 pushed a commit to flip1995/rust that referenced this pull request Dec 21, 2023
Don't check for late-bound vars, check for escaping bound vars

Fixes an assertion that didn't make sense. Many valid and well-formed types *have* late-bound vars (e.g. `for<'a> fn(&'a ())`), they just must not have *escaping* late-bound vars in order to be normalized correctly.

Addresses rust-lang/rust-clippy#11230, cc `@jyn514` and `@matthiaskrgr`

changelog: don't check for late-bound vars, check for escaping bound vars. Addresses rust-lang/rust-clippy#11230
flip1995 pushed a commit to flip1995/rust that referenced this pull request Dec 21, 2023
Don't check for late-bound vars, check for escaping bound vars

Fixes an assertion that didn't make sense. Many valid and well-formed types *have* late-bound vars (e.g. `for<'a> fn(&'a ())`), they just must not have *escaping* late-bound vars in order to be normalized correctly.

Addresses rust-lang/rust-clippy#11230, cc `@jyn514` and `@matthiaskrgr`

changelog: don't check for late-bound vars, check for escaping bound vars. Addresses rust-lang/rust-clippy#11230
xobs pushed a commit to betrusted-io/rust that referenced this pull request Dec 24, 2023
Don't check for late-bound vars, check for escaping bound vars

Fixes an assertion that didn't make sense. Many valid and well-formed types *have* late-bound vars (e.g. `for<'a> fn(&'a ())`), they just must not have *escaping* late-bound vars in order to be normalized correctly.

Addresses rust-lang/rust-clippy#11230, cc `@jyn514` and `@matthiaskrgr`

changelog: don't check for late-bound vars, check for escaping bound vars. Addresses rust-lang/rust-clippy#11230
LucasSte pushed a commit to LucasSte/rust that referenced this pull request Feb 19, 2024
Don't check for late-bound vars, check for escaping bound vars

Fixes an assertion that didn't make sense. Many valid and well-formed types *have* late-bound vars (e.g. `for<'a> fn(&'a ())`), they just must not have *escaping* late-bound vars in order to be normalized correctly.

Addresses rust-lang/rust-clippy#11230, cc `@jyn514` and `@matthiaskrgr`

changelog: don't check for late-bound vars, check for escaping bound vars. Addresses rust-lang/rust-clippy#11230
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.

5 participants