This is a major antipattern IMO since it makes it very difficult to programatically change configuration files. Unfortunately it seems to be all the rage these days to make a DSL for your config files.

I don't understand. Lua config is just Lua data structures. Load Lua data structures, modify them directly because they are the language's native data types, serialize them back to text. How much easier do you want it?

What if the file doesn't just contain literal values in the data structure?

Then yer shooting yer own foot. Don’t put functions or expressions in your “Lua-SON” any more than you would in your JSON.

I guess if you lack confidence in your coworkers’ ability to resist temptation, you could write a checker using Metalua. That would make a good git submit hook.

Doing it “wrong” was one of my fav dev tales. I wrote a custom UI system in OpenGL for an iPhone 1 game (memory budget 32mb). Didn’t have time budget to make a visual editor, so I made up a Py-SON notation that simply loaded as Python. From there I used CTypes to convert the Python data tree into binary files full of arrays of C structs. Loading that in C was just fread(), cast a pointer.

The big win came when we realized we had way too much UI to create and not enough artist time to create it. So, another programmer and I sat down and wrote a suite of Python functions that made generating UI components much easier. It required a programmer-artist pair to use. But, otherwise it would have simply been impossible to complete on time.

That is probably true but I have been changing mine manually and then pushing them via version control.

What do you have in these files that requires this?

One obvious thing I've missed in the past, in some program configuration-files is the ability to have per-host config checked into git.

Sure you can create symlinks so "~/.foo" is a pointer to "~/.foo-www.example.com", or "~/.foo-www.example.net". But having the ability to load a per-host file, natively is a good thing.

I started to get annoyed that my mail-client of choice (mutt) didn't have a real-scripting language, just something that was kinda-sorta-like one, with big holes.

That lead to me writing a console-based email client which has a core written in C++, and the UI and most handling written in Lua.

My configuration file is 100% lua, and the whole system is pretty flexible.

I've stalled over the past year, but I guess that means it is feature-complete with no glaring omissions!

https://github.com/lumail/lumail/