Recently, I was contemplating some new overview documentation on Hugo—from a new-user point of view—that (hypothetically) I might write.
Hugo’s document Customizing a Theme says:
Hugo permits you to supplement or override any theme template or static file, with files in your working directory.
I was contemplating how to write a broad-brush overview of this feature: and how to express the quintessence of it.
I was considering that this feature could be expressed most simply in the following way (employing the concept of filesystem subtrees):
Given a directory named ./themes/, everything under a certain subdirectory of it is fallback for everything outside the ./themes/ directory; ./config determines which subdirectory.
Sometimes expressing a principle in terms of generalities is simpler than being specific. So, it occurred to me that Hugo (hypothetically) could operate more generally as follows:
For each directory (anywhere) named themes/, everything under a certain subdirectory of it is fallback for everything outside that themes/ directory; themes/../config determines which subdirectory.
If Hugo worked that way, an example of a viable project tree would be:
SomeHugoBasedWebsite/
---config.toml
---fileThree
---themes/
------themeTwo/
---------config.toml
---------fileTwo
---------fileThree
---------themes/
------------themeOne/
---------------fileOne
---------------fileTwo
---------------fileThree
So fileOne would be inherited from themeOne, and fileTwo would be inherited from themeTwo.
The source code changes required for this (hypothetical) change in Hugo’s functionality might be quite few.
What new behavior would we (hypothetically) obtain? Perhaps sub-themes, or theme families.
Still, Hugo would work in an unaltered way in its present use cases.