lsif-clang VS The-Open-Book

In the top right corner of the tooltip it will say either "Search-based" or "Precise" - in this case, you're right, we don't have the abseil-cpp repo indexed so it falls back to search-based as you describe.

We do have a C++ code indexer in beta, https://github.com/sourcegraph/lsif-clang - it is based on clang but C++ indexing is notably harder to do automatically/without-setup due to the varying build systems that need to be understood in order to invoke the compiler.

Interesting because on https://lsif.dev/ I see that LSIF support for C++, which basically is just a wrapper around clangd AFAIU, is deprecated. Is there something else that replaced it?

We already have an LSIF indexer for C++ (lsif-clang); however, that is not as feature complete as the other indexers. Moreover, the codebase is forked off of Clang 10, so upgrading to newer Clang versions (and build a SCIP indexer on top of that) will be a challenge.

- Go:

Why are not all repos covered?

Because different languages have different build systems, so inferring the right build commands, dependencies etc. is not so straightforward; these are necessary per-requisites for compiler-accurate cross references. We're working on fixing this with auto-indexing: https://docs.sourcegraph.com/code_intelligence/explanations/...

For C and C++ specifically, auto-indexing is challenging because of the large variety in build systems, informal specification of dependencies (such as in a README instead of a machine-readable format), and platform-specific code.

Outside of auto-indexing, we do have an indexer for C and C++ right now (https://github.com/sourcegraph/lsif-clang) which can be run in CI; that way one can generate an index and upload it to Sourcegraph on a regular basis. It is 'Partially available' (https://docs.sourcegraph.com/code_intelligence/references/in...) right now. We're keenly aware of the interest in C++, and are working our way through different languages based on usage.

Have you seen the "Open Book" project?

https://github.com/joeycastillo/The-Open-Book

Open book project https://github.com/joeycastillo/The-Open-Book

If you want to get all custom, you could build an e-reader https://github.com/joeycastillo/The-Open-Book https://www.tomshardware.com/news/raspberry-pi-pico-powered-open-source-ebook-reader

>I really wish I could have an e-reader, but again, I don't want to spend money on things that will lock me into a single vendor indefinitely and might just arbitrarily go away.

https://github.com/joeycastillo/The-Open-Book

This may be up your alley.

It's not a commercial off the shelf product, but the Open Book uses a 4.2" screen. There are other devices you can find on places like AliBaba that are kinda small. However, in general you won't find a name brand commercial ereader under 6" that isn't ina phone body. There were a couple at 5" back-when but the industry really settled on 6" as the common base size.

This is very useful to see examples of how people have used APIs that are either poorly documented or not at all. Or even that are well documented, really. Going from docs to code is not always straightforward.

To give you just one example, recently I've been using it to find how people have written code to interface with e-ink displays. I usually have the datasheet which lists all the commands the protocol support, but building it all into a valid startup sequence of ~20 commands to activate the display is left as an exercise for the reader.

So the docs will look like this: https://www.waveshare.com/w/upload/6/6a/4.2inch-e-paper-spec...

And what I need is a sequence like this: https://github.com/joeycastillo/The-Open-Book/blob/5c5054c58...

There is a link to the project early in the article: https://github.com/joeycastillo/The-Open-Book