@greg when I press c-c c-d, how does Racket-mode choose between the local documentation copy or the one on http://docs.racket-lang.org\|docs.racket-lang.org?
It asks xref-binding->definition-tag
(from scribble/xref
) whether it knows about the identifier.
If yes, it gets a URL from xref-tag->path+anchor
. In that case IIRC it will be local (modulo whatever config Racket itself offers in this regard).
If not, it treats the thing as a string to search for. This follows the Racket Mode Emacs config variable racket-documentation-search-location
, which can be 'local
or it can be a format string to form a URL using the search string. The default is not local, it’s "<https://docs.racket-lang.org/search/index.html?q=%s>"
.
TL;DR if you want it always local, you probably should change that racket-documentation-search-location
config to 'local
. (I defaulted it to the web because reasons I don’t recall right now, but is probably in some GitHub issues discusson; there were also some PRs I merged from folks wrt doc search w/in the last year.)
FWIW wlangstroth/vim-racket (and consequently my fork under benknoble) do a local doc search when you press K
. I’m not sure we have a way to configure that
Quick question—is there anything we can do to make it so that Racket stops throwing these “read-compiled-linklet: version mismatch” errors? Skipping the compiled file, or recompiling it, anything is probably fine. I recall I asked once before and the answer was that it was hard, but I’m wondering if anything has changed.
I think I’m remembering a justification for searching the web, in the case where xref-binding->definition-tag
fails.
I think it was: one reason it might fail is because a package providing an identifier with that name isn’t installed locally. So it’s a means of discovery.
Now, that doesn’t necessarily mean searching the web is the best default for most users. Maybe it should be local, to be consistent.
That sounds reasonable when the identifier isn’t known locally.
Unfortunately, nothing has changed. I imagine someone recommend the “custom-load” package before, but if not, give that a try.
can the error message be improved? it’s pretty arcane for something that occurs relatively frequently
Ignoring errors is generally bad.