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.

Sign up for GitHub

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

Jump to bottom

Add settings page to Rustdoc for long-term configuration #18167

Closed
Gankra opened this issue Oct 19, 2014 · 5 comments
Closed

Add settings page to Rustdoc for long-term configuration #18167

Gankra opened this issue Oct 19, 2014 · 5 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@Gankra
Copy link
Contributor

Gankra commented Oct 19, 2014

Would use localStorage to maintain state between pages.

Ideas:

  • Collapse permanency settings from rustdoc: make collapsing permanent #17126. Two independent check-boxes:
    • Always collapse function-level docs
    • Always collapse top-level docs
  • Hide deprecated functions
  • Hide unsafe functions
  • Only show stable functions
@steveklabnik steveklabnik added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jan 27, 2015
@azerupi
Copy link
Contributor

azerupi commented Aug 8, 2015

I have used localStorage extensively for the same kind of thing in a project of mine. It's a little bit messy, but maybe it can help :)

https://github.com/azerupi/SOTAwatch-filter/blob/master/development/js/spots/settings.js#L41-L181

@Gankra
Copy link
Contributor Author

Gankra commented Aug 9, 2015

I've also used localStorage a fair amount (granted, 3 years ago): https://github.com/WhatPumpkin/Sburb/blob/master/src/serialization.js#L69-L158

Honestly the main thing that prevented me from ever going at this was building the menus and stuff. UI designers wanted :)

I suppose I could make stuff persist without giving any way to configure...

@azerupi
Copy link
Contributor

azerupi commented Aug 9, 2015

Honestly the main thing that prevented me from ever going at this was building the menus and stuff. UI designers wanted :)

I have a couple of ideas:

  1. Add one more keyboard shortcut. Like the current ? another keyboard shortcut could open an options panel with some check-boxes.
  2. Reduce the width of the search bar a little bit and place an cog icon on the right of it, that opens a panel when clicked.

Another thing I would add to that settings panel is the a toggle for serif / sans-serif font

Like a mentioned in a post on Rust internals, I think it's worth having a centralized place for all the design decisions where designers would be invited to post ideas and mock-ups

@ghost
Copy link

ghost commented Oct 24, 2016

Yes please. Collapsing all of the methods alone would be a huge improvement.

@the8472
Copy link
Member

the8472 commented Nov 25, 2016

Javadoc has a separate method summary table + detailed documentation further down. Since rustdoc does not have that it's necessary to collapse the details every time to get an overview.

I usually have a rough idea what I want and just need to find that one method out of a myriad, so I would prefer the methods to be collapsed by default.

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 22, 2017
This was referenced Aug 1, 2017
Closed
Open
@QuietMisdreavus QuietMisdreavus mentioned this issue Oct 17, 2017
Merged
@steveklabnik steveklabnik mentioned this issue Apr 12, 2018
Closed
@GuillaumeGomez GuillaumeGomez mentioned this issue Apr 13, 2018
Merged
bors added a commit that referenced this issue Apr 22, 2018
@bors
Auto merge of #49954 - GuillaumeGomez:doc-settings, r=ollie27,QuietMi…
28193e8 
…sdreavus

Add rustdoc settings menu

Fixes #18167.

r? @QuietMisdreavus
lnicola pushed a commit to lnicola/rust that referenced this issue Oct 8, 2024
@bors
Auto merge of rust-lang#18167 - SomeoneToIgnore:fat-completions, r=Ve…
4800a0e 
…ykril

internal: Send less data during `textDocument/completion` if possible

Similar to rust-lang/rust-analyzer#15522, stops sending extra data during `textDocument/completion` if that data was set in the client completions resolve capabilities, and sends those only during `completionItem/resolve` requests.
Currently, rust-analyzer sends back all fields (including potentially huge docs) for every completion item which might get large.

Same as the other one, this PR aims to keep the changes minimal and does not remove extra computations for such fields — instead, it just filters them out before sending to the client.

The PR omits primitive, boolean and integer, types such as `deprecated`, `preselect`, `insertTextFormat`, `insertTextMode`, etc.  AND `additionalTextEdits` — this one looks very dangerous to compute for each completion item (as the spec says we ought to if there's no corresponding resolve capabilities provided) due to the diff computations and the fact that this code had been in the resolution for some time.
It would be good to resolve this lazily too, please let me know if it's ok to do.

When tested with Zed which only defines `documentation` and `additionalTextEdits` in its client completion resolve capabilities, rust-analyzer starts to send almost 3 times less characters:

Request:
```json
{"jsonrpc":"2.0","id":104,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///Users/someonetoignore/work/rust-analyzer/crates/ide/src/inlay_hints.rs"},"position":{"line":90,"character":14},"context":{"triggerKind":1}}}
```

<img width="1338" alt="image" src="https://github.com/user-attachments/assets/104f19b5-7095-4fc1-b008-5d829623b2e2">

Before: 381944 characters
[before.json](https://github.com/user-attachments/files/17092385/before.json)

After: 140503 characters
[after.json](https://github.com/user-attachments/files/17092386/after.json)

After Zed's [patch](zed-industries/zed#18212) to enable all resolving possible: 84452 characters
[after-after.json](https://github.com/user-attachments/files/17092755/after-after.json)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@steveklabnik @the8472 @Gankra @Mark-Simulacrum @azerupi