Structured configuration: change the value, not the punctuation

Why a specialized editor can be simpler than a text editor

Imagine a large configuration file where you only need to change application.debug. In a normal editor you search for the section, confirm the correct occurrence, preserve punctuation and save the whole file. A structured command lets you name the logical path directly.

This is not about replacing source editing. It is about matching the tool to the intention. If the intention is a value, address the value.

One rhythm across several formats

The structured modules share a deliberately similar grammar: open a file, read a key, search, write with :, delete a key, validate with -c, or dump the serialized source. After one format, the others feel familiar.

Opening a structured file also makes it active. $ can then stand in for that path, which keeps a sequence readable while you work on several keys in the same file.

INI: sections and simple values

INI is common in configuration because it is compact and readable: sections group key/value pairs. In lil-terminal, dotted paths let you address that logical structure without scrolling through the file.

Use INI when the format fits the software you are configuring; do not choose a format merely because a terminal command exists for it. The command is there to make an existing format easier to handle.

JSON: objects, arrays and typed values

For this practice file, open project/config/app.json with code -n, paste the small {} starter shown below, save it, and only then run the json commands. JSON must already be valid before the structured editor can work with it.

JSON represents nested objects and arrays and is everywhere in APIs, application settings and package metadata. The punctuation is strict, so a focused path-based change can avoid accidental commas or braces.

Values keep their types: a number should stay a number, a boolean should stay a boolean, and quoted text is text. After changes, -c is a useful explicit validation step.

{}

YAML, TOML, XML, conf and properties

YAML is indentation-oriented and common in deployment files; TOML favors explicit tables and typed values; XML represents elements and attributes; .conf and .properties families are common in server and application configuration. They solve overlapping problems with different syntax traditions.

lil exposes a common day-to-day surface for supported structures, but it does not pretend the formats are identical. Advanced YAML features, unusual XML constructs or software-specific syntax may be better handled as source text in code.

Validate the model; dump only when you need the source

-c asks the module to validate the current document. dump returns a serialized source representation. Those are different operations: one answers “is this valid for the handler?”, the other answers “what source would this data produce?”.

Structured writes may normalize formatting, ordering or comments because the data is parsed and serialized. If exact source formatting is part of the requirement, use edit or code instead.

Know when to return to the code editor

Use the structured module for targeted values, searches and validation. Use code when comments, hand-aligned layout, advanced format features or a broader refactor matter. Neither mode is the “advanced” one; they answer different questions.

A good operator switches views without ideology: structure when meaning matters, source when source matters.

Configuration changes are excellent script material

A verified sequence of configuration changes is exactly the kind of knowledge worth saving. Instead of keeping a note that says “remember to enable debug and change the name”, save the commands that perform those changes and validate the document.

The script becomes documentation that can execute. On another project you can review it, adjust the values and reproduce the same environment with much less guesswork.