panda3d-docs
panda3d-docs copied to clipboard
Set the default_role to any
It can be quite tedious (and hurt readability) to keep typing out the roles for external references:
The method :meth:`~.NodePath.set_shader_input()` stores data that can be accessed
by the shader. It is possible to store data of type :class:`.Texture`,
:class:`.NodePath`, and any vector object.
Sphinx allows you to set the default_role, which will be used whenever single backticks are used without a prefix. I suggest setting it to :any:, which will make Sphinx automatically figure out what you are talking about and link it as appropriate. I think we can get the above down to:
The method `~NodePath.set_shader_input()` stores data that can be accessed by
the shader. It is possible to store data of type `Texture`, `NodePath`, and any
vector object.
:any: will also find glossary terms, or really any kind of reference (as the name suggests), which might be useful in text that is continuously referring to things like `render` or other Panda-specific terms.
Thoughts?
Any downside to this? It sounds good to me.
I don't know that these are valid downsides, but I could imagine:
- People might be used to the default behavior of emphasis (though they should be using
*thing*if they want emphasis) - Possible ambiguity (eg.
rendercould be both a term and a variable), although in those cases we could still explicitly disambiguate as needed. - It's hard to go back if we change our mind (especially if we were to decide to use backticks for something else)
That said, Sphinx makes it pretty easy to customize the behavior of the default role if we needed to (eg. to prefer terms over variables, or vice versa).
Yeah, those seem pretty easy-to-work-around downsides for the benefits. Have we searched the current codebase for instances of using backticks for emphasis?
Just did (it was easy to find them—I just defined a custom role that raised an error message and set the default_role to that). All but one case actually used it in error, and most cases should have used double-backticks instead. (I imagine the author probably was used to Markdown, or this was due to a conversion error.) Fixed all cases in 18d6571e4d94035f1d1e453a7c290a55837a0aea.