Splitting Your Config

As your config grows, you can split it across several Lua files instead of one large sweets.lua. sweets.include(...) loads another file inline, exactly as if its contents were pasted at that point.

sweets.include("bindings.lua")
sweets.include("rules.lua")
sweets.include("monitors.lua")

A common layout is a small top-level sweets.lua that only pulls in focused files:

sweets.general({ mod_key = "SUPER" })

sweets.include("layout.lua")
sweets.include("bindings.lua")
sweets.include("autostart.lua")

sweets.bind("MOD+Return", "spawn", "foot")
sweets.bind("MOD+q", "close")
for i = 1, 9 do
  sweets.bind("MOD+" .. i, "workspace", i)
end

Included files share the same sweets table and the same global scope, so any Lua variable or function you define before an include is visible inside the included file, and vice versa.

Path resolution

Paths are resolved relative to the file that calls include, not the current working directory:

• A relative path like "bindings.lua" or "parts/rules.lua" is looked up next to the including file.
• An absolute path ("/etc/sweets/shared.lua") is used as-is.
• A leading ~ expands to your home directory.

Because resolution is relative to the including file, nested includes just work: a file in parts/ that includes "extra.lua" finds parts/extra.lua.

Safe by design

• Missing files are an error. If an included file does not exist, the load fails, the on-screen error bar appears, and Sweets keeps running on the last good configuration. This catches typos immediately rather than silently ignoring them.
• Cycles and repeats are ignored. Each file is pulled in at most once per load, so two files including each other — or the same file included twice — will not loop. Deeply nested includes are capped as a final safeguard.
• Errors point at the real file. A syntax error or bad value inside an included file is reported with that file's name and line number.