You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By adding and overriding code, it's possible to achieve quite substantial customisations of Furo.
However, this has some limitations. Beyond a certain point it feels a bit crude to bolt on extensive customisation in hand-written CSS to the elegantly-compiled SASS output. It would be nicer to apply some customisation in the SASS itself, in the context where these customisations belong, so it's easier to understand what they are doing.
With every new version of Furo, the ground on which you were building your customisation might shift under your feet unless you check whether the things that you were overriding have changed.
A solution would be if I could include my own fork of Furo as a Git submodule in my documentation project:
Then, I could point my project to a theme that is now local to it.
html_theme_path = ['furo/src/furo/theme']
I could maintain all my changes in the SASS. When pulling in upstream changes into my fork of Furo, I would quickly see whether new commits in Furo have implications for my customisation, and be able deal with them.
Because I would be maintaining a fork of Furo, I would be able to test my SASS changes against the full panoply of example content that the Furo demo provides, and do that independently of my own content.
However because my fork would be available inside my own project, I could also test it - live - against my own content.
Or, as long as I had compiled the SASS into furo.css, I would have my styles compressed and optimised as part of my project.
However: I run into the 'furo_pygments' is undefined" issue described in #204 ("Allow inheriting from Furo") and #293 (which I think is very close to what I am wanting to do).
Clearly, documentation can use a locally-available version of Furo, because that is what the demo content does, so I feel I can't be very far away from achieving that from my own project and content. It would be an excellent workflow for the maintainer of a Furo-based theme.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
By adding and overriding code, it's possible to achieve quite substantial customisations of Furo.
However, this has some limitations. Beyond a certain point it feels a bit crude to bolt on extensive customisation in hand-written CSS to the elegantly-compiled SASS output. It would be nicer to apply some customisation in the SASS itself, in the context where these customisations belong, so it's easier to understand what they are doing.
With every new version of Furo, the ground on which you were building your customisation might shift under your feet unless you check whether the things that you were overriding have changed.
A solution would be if I could include my own fork of Furo as a Git submodule in my documentation project:
git submodule add -b my_customised_branch [email protected]:evildmp/furo.git
Then, I could point my project to a theme that is now local to it.
html_theme_path = ['furo/src/furo/theme']
I could maintain all my changes in the SASS. When pulling in upstream changes into my fork of Furo, I would quickly see whether new commits in Furo have implications for my customisation, and be able deal with them.
Because I would be maintaining a fork of Furo, I would be able to test my SASS changes against the full panoply of example content that the Furo demo provides, and do that independently of my own content.
However because my fork would be available inside my own project, I could also test it - live - against my own content.
Or, as long as I had compiled the SASS into furo.css, I would have my styles compressed and optimised as part of my project.
However: I run into the
'furo_pygments' is undefined"
issue described in #204 ("Allow inheriting from Furo") and #293 (which I think is very close to what I am wanting to do).Clearly, documentation can use a locally-available version of Furo, because that is what the demo content does, so I feel I can't be very far away from achieving that from my own project and content. It would be an excellent workflow for the maintainer of a Furo-based theme.
Beta Was this translation helpful? Give feedback.
All reactions