Open D-Vaillant opened 6 years ago
If I understand this right... config.base
and block ending markers
is not related.
Phrasing out config.base
mean users will always have to specify config.base
in j4-make-config
command.
1) j4-make-config
is geared toward i3
config.
2) base16-builder
is geared toward all files via --file FILE
and must contain base16
block markers inside for this to work... and can be outputted via --output FILE
. What happen when users don't specify --output FILE
? Does it just print things?
The difference is that instead of making users specify --base config.base
every time, it's done automatically in j4-make-config
.
Supposedly if we can make config.base
optional in j4-make-config
, then it might behave more similar to base16-builder
. Maybe we can simplify by using --append
instead of new --base
for config.base
. We don't have a way to override output file too, so I guess we could make --output
too just in case.
It might be traditional to have users always specifying what config(base) to load and where to always dump. j4-make-config
make things a bit easier by scanning for config.base
+ dumping the config file in same place it found config.base
instead of always requiring two arguments.
I currently don't see or understand the benefits of adding end markers when start markers works okay here. We could make things a bit better by stripping empty lines or such...(empty lines are used to make room between markers in themes) before dumping. Additionally, implementing end markers would mean we need to update all themes with this too... which could look ugly or plain stupid. This would also inflict small pain on users.
As for safety checking, we likely can break
on prefix block marker or reach EOF (then strip lines mentioned above)... not needing any end markers in first place. Do you have a branch?
What happen when users don't specify --output FILE? Does it just print things? IIRC it just yells at you.
The idea is that there sn' a config.base
file at all, just a config
file that does what config.base
did. The end markers are so we can delineate which parts of the file (after processing) correspond to templates that we would delete and replace whenever we ran j4-make-config
. We wouldn't need to change the themes at all since the ending markers can easily be part of the logic when we're rewriting config
I'll branch it off from classes
; I've put that on the backburner but I'll do some bughunting with it before I implement this.
I wrote a branch: https://github.com/D-Vaillant/j4-make-config/tree/class-baseless
I haven't tested it that heavily yet but it (apparently) works. There's some behavior I need to squash (trimming excess newlines) and I want to add in a real quick "backup original config file" system.
Right now there's a
config.base
file with config block markers that gets compiled intoconfig
. If we introduce an ending marker we can just have config and replace everything in the block with whatever else we're loading. Base16-Builder works this way, for example. So something like:We can add some safety checking - freaking out if we see another block marker before we see the end marker or if we reach EOF or however.