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

(doc) Change search placeholder text. #15012

Closed
wants to merge 1 commit into from
Closed

(doc) Change search placeholder text. #15012

wants to merge 1 commit into from

Conversation

zzmp
Copy link
Contributor

@zzmp zzmp commented Jun 18, 2014

Update placeholder text to make keyboard shortcuts more apparent. As discussed in #15010.

Update placeholder text to make keyboard shortcuts more apparent.
@zzmp
Copy link
Contributor Author

zzmp commented Jun 18, 2014

@kballard, as a separate issue, ? does not work for me in Chrome or Firefox, although it is documented in the raw html.

I'm not sure if I should be rebasing to take that out of the placeholder, or I should be opening a separate issue to fix whatever javascript should be capturing that keystroke (or both).

@lilyball
Copy link
Contributor

@zzmp I think you should just open a separate PR to fix it.

FWIW, I just looked a bit, and the current code is relying on the keyCode property of the event. As far as I'm aware, this is a platform- and implementation-dependent value. For example, in Safari on my computer, both slash (/) and question mark (?) have the keyCode of 191 (with the shiftKey to distinguish them). The code right now is looking for 188.

It seems that on IE and Firefox, the proper solution is to use the key property, and on Safari and Chrome, the proper solution is to use the keyIdentifier property (of the originalEvent; apparently JQuery doesn't bother surfacing that up onto its wrapper object). For the latter, the expected value for ? is U+003F. For the former, I'm not sure, you can test on Firefox to find out.

I'm actually vaguely surprised that s works in Safari.

I'm also surprised JQuery doesn't apparently abstract this away for you.

@zzmp
Copy link
Contributor Author

zzmp commented Jun 18, 2014

@kballard There's a nifty mousetrap library for JavaScript that abstracts all this for you. If you look at the W3 specs, a lot of the keyCode like properties are either deprecated or up in the air.

I'll get to the PR by EOD if noone beats me to it. Thanks for the tips.

bors added a commit that referenced this pull request Jun 19, 2014
Continuing from #15012, this makes four changes to the `rustdoc` static files.

- Change the placeholder text of the search bar to `Click or press 'S' to search, '?' for more options...` to make keyboard hotkeys more apparent (capitalizing the `S` to match the help text).
- Change the `main.js` file to use browser-normalized key codes (`e.which`, from `jQuery`), instead of `e.keyCode`.
- Change the key code for `?` to be the correct `191` instead of `188`, so that the hotkey works to bring up search information.
- Change the search information to display `tab` and `shift+tab` instead of `up` and `down`, as those do not yet work outside of Firefox (see #15011). Also, adjust the height so it does not cut off the help text.

<s>I've also opened up #15038 about the non-functional `up` and `down` functionality, although this does nothing to fix it.</s>
lnicola pushed a commit to lnicola/rust that referenced this pull request Jun 19, 2023
…r=HKalbasi

Infer return type for async function in `generate_function`

Part of rust-lang#10122

In `generate_function` assist, when we infer the return type of async function we're generating, we should retrieve the type of parent await expression rather than the call expression itself.
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