lobsters score: 2 · tags: c, c++, practices, python, rust
Sounds like the generator side of what I’m slowly poking away at by writing a new frontend for the Recoll full-text indexer.
(So far, the only publicly visible part is that I upstreamed support for some new query parameters in CHMate to allow pre-opening a
.chmfile to a specific page, pre-filling a search string, and externally specifying a zoom level to harmonize font sizes.)In my case, I’m sort of aiming to serve a similar desire as you are, but the API docs for my retrocomputing hobby are stuff like scans of Windows 3.1 books from 1993… so I’m starting from exploring how far I can go to push something that currently tries to be a local Google (right down to the unstructured preview snippets) into being more like Dash/Zeal/DevDocs despite running on top of source data that doesn’t meet it in the middle.
Maybe I’ll look into sitting it on top of your efforts once I get past phases one (improve the Recoll UX for this task), two (improve Recoll’s format-support/text-ingestion filters), and three (write tooling to help streamline things like finding and fixing PDFs with incomplete text underlays). After all, a big part of my design goal is to integrate things like PDF.js, CHMate, etc. for preview that’s as snappy as using the
pdftotext-based preview in Recoll’s current Qt GUI but easier on the eyes.
score 1 · canonical
For example, given a structured search query like vec -> usize, rustdoc’s search engine results UI only surfaces functions that take in a vec as an arg and return usize.
This is something I’ve not realized during the few years I’ve used rust. Happy to find out today
score 1 · canonical
*nod* Surfacing those kinds of things is difficult. rustdoc already has a help button which mentions it, and I missed it for ages too.
I’m hoping that, for the Recoll frontend I’m working on, building the quick reference popup around a categorized table with sample query snippets in the left column will help to eye-catch more effectively where appropriate. (But then that’s just a running theme in my design. More structure, less freeform text.)
score 1 · canonical
I have this problem also. So far my approach is to transform tool outputs into something markdownish and then use mkdocs on it all. But I definitely ha e some custom scripts and transforms as a result
score 1 · canonical
Beautiful results. I’ve done this in the past and gave up on consistent theming.
The 1st result comes from Doxygen, the 2nd and 3rd come from Sphinx, and the 4th comes from rustdoc.
This surprises me. If I’m looking at the rust docs, getting results for C/C++ would feel distracting. Is there a way to show just the rust docs if I’ve drilled down to that language?
score 1 · canonical
Beautiful results
Thank you (and thanks for reading)
gave up on consistent theming
IME consistent fonts go a long way. CSS vars make it much more manageable now, too
If I’m looking at the rust docs, getting results for C/C++ would feel distracting
I’ve gone back and forth on this. My operating theory is that the top-level search UX should be consistent across the site, no matter what page you’re on. Note that the rustdoc search is still available when you’re on rustdoc pages. So there’s 2 search boxes on rustdoc pages. Which is potentially way more confusing. Not sure what the right move is here. After 6 months I’ll have more opinions
Is there a way to show just the rust docs if I’ve drilled down to that language?
I think you’d have to manually filter by URL, but yes, should be totally feasible via Pagefind search API: https://pagefind.app/docs/api/
I will update the post to discuss CSS stuff in more detail this week, that was another thing I meant to cover but didn’t have time for
score 1 · canonical
Note that the rustdoc search is still available when you’re on rustdoc pages.
Oh I looked right past it, that is helpful.
score 1 · canonical