Description
Say you search for drivers/cpuidle
, no such identifier exists (related #293 bug). In that case, we could check if the path exists and redirect to it if it does.
Currently we get redirected to /linux/latest/A/ident/drivers/cpuidle
. We should end up at /linux/latest/source/drivers/cpuidle
.
Code that does the 302 redirect is (I think):
Lines 99 to 102 in fc47224
It is weird, the code does not even check that the request is of type POST (as seen in the front-end form).
Now that autocomplete is re-enabled, we could integrate into it. Ideally, that part of autocomplete would be done on the front-end, with a file/dir list available for each (project, version) tuple. Compressed, it should not be too much traffic. And it is easily cache-able.
Idea: we could also match on filename. Say pcm1789
, those are the matches:
⟩ fd pcm1789
Documentation/devicetree/bindings/sound/pcm1789.txt
sound/soc/codecs/pcm1789-i2c.c
sound/soc/codecs/pcm1789.c
sound/soc/codecs/pcm1789.h
If you search for pcm1789.c
: no symbol is named that way, only one file has that exact name.
To have that working, we should integrate that into autocomplete as well. Autocomplete would have entry types (file, identifier, etc.).
Activity