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
It would be nice to have an ability to include another PITCHME.yaml in PITCHME.yaml.
Implementation
Just use simple include key with path to another PITCHME.yaml. For simplicity and consistency with other features, the path is relative to the repository root: include: PITCHME.yaml
Reasoning
Some settings in PITCHME.yaml can be specific for presentations, som other settings can be global.
For example there will be masterPITCHME.yaml in the root of the repository, where will be specified colors, fonts, code highlighting style, custom CSS etc. In general there would be global design/theme settings.
And there will be another PITCHME.yaml next to the presentation itself (next to PITCHME.md). In this yaml file, we can just include the master yaml and add/update other setting. For example:
include: PITCHME.yaml # Global settings for all my presentsations.# Every presentation has its own title.title: My Super Presentation# I want different logos for different presentations, or maybe I do not want any logo in some.logo: https://example.com/path/to/logo.png
Things to consider
Depth of including. Again for simplicity, I believe that it is enough to support just one level of include (the same as including PITCHME.md files). So included PITCHME.yaml cannot contain include key.
In general, I think that mostly the include will be at the begining of the file. But i should be clear the behavior if the include is somewher in the middle. Possibilities:
Force the include (if present) to be the first key in .yaml. Show error if it is not the case.
Allow include to be anywhere, but always process it first. So local settings will always override global settings, even if they are before the include.
Allow include to be anywhere and process the files from top to bottom. So process settings in local file, then include global file and process that - it may override already set settings. Then process the rest of local file, which will override any previous settings. This is probably the expected behavior.
The text was updated successfully, but these errors were encountered:
Hi Stano, thanks for submitting this interesting feature request. And for providing a clear, detailed description. My gut reaction, very nice idea. I don't know when I can get to this but for right now I'll simply keep the thread open to see if others in the GitPitch community also express interest in this feature with an up-vote or additional commentary. Lets see what happens. Cheers, David.
This would be very useful for modular courseware slides. I could have a master yaml to keep a consistent look and feel to all my courses but override logo or footer with something course specific.
I also see this a very nice to have. For a full level course where you will have several modules having a global look and feel while having separate details for individual modules would be very nice.
It would be nice to have an ability to include another
PITCHME.yaml
inPITCHME.yaml
.Implementation
Just use simple
include
key with path to anotherPITCHME.yaml
. For simplicity and consistency with other features, the path is relative to the repository root:include: PITCHME.yaml
Reasoning
Some settings in
PITCHME.yaml
can be specific for presentations, som other settings can be global.For example there will be master
PITCHME.yaml
in the root of the repository, where will be specified colors, fonts, code highlighting style, custom CSS etc. In general there would be global design/theme settings.And there will be another
PITCHME.yaml
next to the presentation itself (next toPITCHME.md
). In thisyaml
file, we can just include the masteryaml
and add/update other setting. For example:Things to consider
PITCHME.md
files). So includedPITCHME.yaml
cannot containinclude
key.include
will be at the begining of the file. But i should be clear the behavior if the include is somewher in the middle. Possibilities:include
(if present) to be the first key in.yaml
. Show error if it is not the case.include
to be anywhere, but always process it first. So local settings will always override global settings, even if they are before theinclude
.include
to be anywhere and process the files from top to bottom. So process settings in local file, then include global file and process that - it may override already set settings. Then process the rest of local file, which will override any previous settings. This is probably the expected behavior.The text was updated successfully, but these errors were encountered: