It's just part of what I call the config pendulum.
Simple config -> (Need to do more complicated things) -> Add override levels -> (Need even more flexibility) -> Add a Turing complete language -> (Things get ridiculous, lots of spaghetti code outside of version control. Time for a reset) -> goto "Simple config"
It's fine. I am not saying it's wrong or right. I've gone through the cycle a few times in some projects. On the other hand, think of it as your project is lucky to be used long enough to have these problems. To feel better about it think of it as a spiral. The next "Simple config" is a slightly better version of the first.
That's clever insight. If it was lisp from the beginning, maybe would be more straightforward. It's as simple as code can get, according to Uncle Bob, while still being expressive. It's no wonder Emacs still reigns supreme. Well, I am happy with Niri's kdl approach for the time being.
I like to have a simple config AND a real scripting language. That way, the UX for changing "simple" things remains straightforward (you can even add a config editor panel), while for less simple things you can use a real programming language (reducing pressure from the "simple" config to turn into a DSL).
I would disagree on that one. Ninja config might not be turing complete, but they're generated by turing-complete tools (usually cmake). Nobody writes ninja by hand, thus I would argue it's irrelevant!
GN tool that is used in Chromium to generate ninja files has much more restrictive language than CMake or make. And even its more complex features are mostly workarounds or escape hatches to deal with legacy setups.
That's because setup.py was objectively a mistake. In order to know how to run the package you need to know its dependencies, which requires evaluating setup.py, but you cannot evaluate setup.py until you know the dependencies, which requires you to evaluate setup.py, and so on. The pyproject.toml is plain text where you specify the build backend and its options, and the build system can be as complex of a program as need by.
If anything, pyproject.toml is an example of taking the idea of programmable configuration to its next conclusion. The build system is part of the configuration and it's more than a simple script, it's an entire application. You just plug in its name into the universal entry point pyproject.toml.
Python went from setup.py to pyproject.toml, but pyproject.toml declares a build-system, which is another package which all the complex logic from setup.py.
Granted, it's a "simpler" config syntax, but the total system complexity has not decreased.
Or to be more specific, issue isn't text/templating as such. It is a fine templating language for text.
But to use a text templating language to generate YAML, which is not only structured, making it a bad match for character based templating with no knowledge of syntax, but indentation-based, making the combination almost seem like a joke.
Helm charts must be the worst engineering solution I have seen in popular use. First time I saw it I didn't believe it, that this was something people did, for real.
I wouldn't say text/template is terribly weird per se, and it's quite reminiscent of Jinja. But what is awful is using a text templating language to generate yaml with the correct level of indentation, and that's where 75% of Helm's problems lie; the other 25% is putting too much logic in templates while working with the clumsy workarounds to text/template having no capability of defining custom functions.
You actually can define custom functions as named templates, but they're definitely not pretty, and would almost certainly push you towards the "just allow us to write code using a normal programming language" side of the argument.
there's a rare form of that where it goes from( simple -> programming language -> language with DSL support -> simple dsl ) ; emacs has followed this model a bit.
Emacs seems to do a pretty good job handling this with the "Customize" interface. Presents a bunch of variables the user is intended to customise in something resembling a familiar interface, then it inserts the values into the Elisp init file. Someone could use and customise Emacs for years and never really touch Elisp directly. But then, oh, those text fields actually take lists, which in Emacs Lisp is the same as taking code. Maybe you use that for a while until you get comfortable and wanna try modifying something not surfaced in "customize", where you can discover init.el, etc. Etc. It's not perfect, but to me it's really close, it's the model of progression I wish all UIs for customisation used, personally.
I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying.
I have to ask…why do people want a Turing complete language to configure stuff? I use Sway personally, which is very configurable but for any even remotely complicated logic I shell out to a set of Rust programs.
If you look at hyprland config, you can see why they went with it.
Much like vim/neovim config, people want to do things like register a callback that fires to determine the window title and things that are much more advanced than that, like layout management.
When I was using sway, I was using its IPC or worse (https://github.com/johnae/persway) to do advanced things, and Lua scripting in the first class config would have been a much better UX.
It looks like the previous hyprland config language was already getting close to being Turing complete;
Already has variable substitution and math, it seems to falls short of Turing completeness only because I don't see any form of recursion. But recursion is something it could accidentally gain if someone decided to add templating to the language.
Besides, looks the config files can call out to external executables, which absolutely are Turing complete. And moving to lua might actually simplify configs by allowing more things to be done inside the config system, rather than calling out.
I did run Awesome for awhile and I liked it, but I never used the Lua config for the most trivial things so it never got in the way of anything.
I never found that Sway too annoying to just use the shell commands to grab/modify the current state of Sway (https://github.com/tombert/rs-swanbar) and just use a "real" programming language to actually do any kind of programming logic. To each their own!
I have to agree. There are things that I want to do with my sway scratchpad that are just not possible because the config vocab is so limited. I might port my config to hyprland and give it a shot.
So you don't like using programming languages as config languages, so you:
1. Use a declarative-style format for config, which is fine, I guess;
2. ... and when that inevitably fails, you... use a programming language?
Some people -- not all, but some -- may prefer to skip the first step and go straight for the second option. Particularly if it's a complex thing indeed like a build system and not, y'know, configuring your blog.
The theoretical difference in power between a non-Turing complete declarative language and a turing complete one is irrelevant in practice. Datalog is a decidable, declarative subset of Turing-complete Prolog. It's also EXPTIME complete. I don't think we exclude any real use cases by prohibiting super-exponential algorithms.
The problem is shitty config languages. I wouldn't group xaml in the same category as dhall for example.
It's interesting because this is exactly what I used to do for my hyprland config (which the op is about). I had some keybinds that would shell out and use a script with the hyprctl cli.
Now it's all a single simple lua function and 3x as fast... I think this change is great.
Those aren't the only two options. There are non-Turing complete config languages like Cue, Dhall, and Jsonnet that are designed to complete and be consistent. They work well when did to generate static config from some dynamic input generated by regular program.
> 2. ... and when that inevitably fails, you... use a programming language?
Maybe it fails because you are trying to solve a problem with a configuration when it should be solved by a function implemented in the program you are trying to use.
It is good to keep a configuration simple enough that it doesn't need to be a programming language.
The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits. No need to end up contemplating some sort of for-loop macro with another key referencing the loop variable, when you can just have a for loop.
I find TOML, in addition to being very readable, to be great at automatically restricting config complexity by making nested lists of tables miserable. If your config sucks at being TOML, it should be JS or Python. (Not a fan of Lua.)
> The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits
That’s where you add a plugin system or an ipc mechanism, not a whole programming language.
Lots of people start out with a non-programmable config format. But, as their situation becomes more complicated, they end up shoehorning in programmable-ish features until they realize they are running straight into https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule and decide to do it properly.
I mean, fair enough I guess. I've accidentally more-or-less reinvented interpreters on two separate occasions (both times using JSON as a quasi-AST), so I understand it.
I guess I just feel like if you feel like you need programming constructs in your configuration, its approaching it from the wrong angle, and it should instead be handled via plugins.
I feel like configuration itself should be a "dumb" format like JSON, and when you want to do anything that can't be accomplished by plain JSON, you should allow for easy development of plugins.
Speaking personally, there are essentially two distinct reasons I like having programmable config languages:
- For personal application config (window manager, shell, text editor, etc), I find I often want to have site-specific configuration, but I also want identical configuration files at every workstation. My laptop probably needs slightly different keybindings than my desktop, my $PATH and text editor needs to be configured a bit differently for work than for personal use, etc. When the configuration is done with a real programming language, this is always straightforward, when it's done via a json/yml/toml file, it's usually a huge pain in the ass.
- You want templating for your configuration, to improve readability, reduce typos and configuration drift, &c, but if you give programmers an inch with any sort of templating system, they will eventually take a mile and figure out how to smuggle Turing-completeness (or, at least, for-loops and variable binding and probably closures) into their configs. If you have a real programming language, this is fine, because the programming language was designed to make loops and conditionals and function calls readable, and probably has decent tooling to boot, but if they're doing it with, say, Mustache-templated YAML, you will have an unreadable mess that is extremely unpleasant to work with.
The usual answer is "config macros", because if you don't give people something Turing complete they'll just m4 their way into Turing completeness and that isn't really an improvement. (Starlark in Bazel, etc.)
Half of me agrees with you. As someone who used to tinker with neovim all day I've had to learn just because you can program the problem doesn't mean you should and stick to a relatively minimal config.
Still, its a valid design choice with different design decisions compared to sway. But that's the point you get to choose.
Hyprland is much more "build your workspace with legos" so having a full lang like lua makes sense to properly integrate the various pieces.
All these window managers have a Turing complete configuration language, because you need to do things in response to events (keyboard hotkeys etc). It's just that for most of them, the "Turing completeness" happens through passing around strings with shell snippets. Might as well be a Lua callback function.
Because there's a never-ending stream of plausible use cases where it just missing one little option. Just look at the web: people have done all sorts of horrible stuff in Javascript to make up for missing HTML / CSS properties.
At a certain point it becomes incredibly tempting to just give up on playing whack-a-mole and let the most demanding users do it themselves using a proper programming language.
I have switched from FVWM to awesome because of Lua. Many years later, I have switched to i3 because it's not using a programming language for configuration. It's fine to have a configuration language if you have time to maintain, but your configuration can become quite complex and difficult to evolve. And it is also far more subject to breakage when upgrading.
I think I've found balance by using a Python daemon as a "companion" for my i3 configuration. It listens and react to event. It enhances the configuration, so when it's broken, it's not a big deal. And the interface exposed by i3 is smaller, so less risk of breakage. https://vincent.bernat.ch/en/blog/2021-i3-window-manager#i3-...
> I have to ask…why do people want a Turing complete language to configure stuff?
What's the alternative? Petition the maintainer to add every little feature any random user might want? Or just do it yourself in a few lines of code?
Case in point, when I was still using BSPWM I did no like how if there was only one window on the desktop it would still get an outline. So I wrote 14 lines of Awk (BSPWM lets you use any language) to get what I want. This was only possible because BSPWM gives me all the primitive building blocks and lets me go wild with them. Sure, if all you want to do is set a few colors and numbers that's overkill, but any power user will sooner or later find himself thinking "oh, if only I could do X when Y unless Z".
I think having good plugin support is a better way to do it. Keep the most obvious configuration options behind a "dumb" config language like JSON or something, but create a framework to add functionality via a plugin API.
> I have to ask…why do people want a Turing complete language to configure stuff?
I don't understand this either. IMO, the current SOTA tool for configuration is CUE, because it is the only one that lets you write schemas for arbitrary refinements. I haven't used it myself, but my understanding is that everybody should be writing configurations in something like this instead of YAML, TOML, HCL, or a custom DSL with no tooling. And yes, definitely not in a Turing complete programing language.
I don't dislike it but I do think it's interesting that a number of minimalist WMs seem to have converged on the idea of code as config. I have used AwesomeWM for years and love its Lua configuration for providing infinite flexibility. When I was recently looking for something like AwesomeWM but in Wayland I toyed with the idea of moving to something with a simpler config format (and Hyprland was one of the options I considered). I can see the benefit of the simplicity but I guess for the kinds of users that use these WMs, maximum configurability probably trumps everything else. (Currently I am using SomeWM which is just an attempt to get something as close as possible to AwesomeWM in Wayland.)
Personally I have grown a bit frustrated with Lua as a language, but at the same time can see why it would be a good choice for this use case.
It smells like a variant of inner platform effect. Where in order to save you from programming the the config is super flexible, What is missed is that you are still programming only now you have to do it in some weird context.
At least in this case it is an actual programming language instead of XML or YAML like so many of them.
An alternative slightly more charitable interpretation is this is the engine/gamelogic pattern. But the difference between the two is more subtle than it naively appears depending largely on proper layer segmentation.
I would agree that turing-complete config is more trouble than it's worth when the config is something you might need to reason over, such as a build definition in Gradle. But for something like a window manager config where everyone's config is a snowflake, it's kind of ideal. Horses for courses and all that.
if you get into a config system that's complicated enough, and has modularization or inheritance, you'll know that the semantics of "remove this" "add that", override this, default to this, this stuff is hard to express in most config languages, or worse, you start enforcing application level semantics. when you have turing complete language you just ... do those things. we reduced the configuration data of a tool suite once by 90%+ by moving from json to python. there was a tremendous amount of duplication and overlap, with tons of TINY exceptions and variations. it was so hard to see those differences, brittle to maintain, things would get stale, ... moving to python you basically had the "base" thing expressed in one file, and a bunch of tiny delta files encoding the exact deviations. All those deviations were of the forms I described above. Adding a thing to a list. Removing a thign from a list. Overriding a whole list. Do a thing if not already done. And so on. It's also then easy to build all kinds of diagnostics, validators, etc, right into the same framework, without having to munge the data into some other form first.
It depends a lot on the config language. Gradle has the uncanny ability to be a "worst of both worlds" option, where there are not many upsides to its using a full language for its configuration. Build configuration is also a space where people and even some tooling seem to forget about good engineering practices, giving birth to fragile builds that people are afraid to modify and improve.
I think the progession is like 1) Oh, I can break stuff by changing a config value - it doesn't protect me. 2) Oh, I didn't think X would need to be configurable. 3) With code I can colocate the values with the code that uses them - easier to understand, and I can "configure" anything I want. 4) Why are we using configs?
Yeah I think there are two basic routes that work. Either you have a declarative configuration, or you go the route of Emacs and make the entire thing programmable.
Turing complete configuration languages suck and makes everything slow, janky and difficult to reason about.
I think INI-style config is one of the few good things that came out of the Microsoft/Windows ecosystem. Shame that it is so underspecified. We have TOML, of course, but I think for stupid config even that is too much.
The intersection of INI and TOML would be perfect.
All scalar types other than strings (especially nonsense like datetimes). I'm already ingesting the configuration file as a string and parsing it into a language with actual types, e.g. Rust, and the act of parsing it into my defined configuration type will itself identify any problems with the config; having half-assed types like "int" in the config file format itself is not only useless, it's counterproductive because it requires people to ask questions like "okay, but what actually is the maximum range of integer values allowed to be contained in this type?". Just enforce UTF-8 encoded string values and let me take care of data validation.
You won't end up with a mix in the same program unless the code that you're using to parse the config is deliberately written to allow a mix, which no sane code owner would allow. And even if it did, that still wouldn't be enough to outweigh the aforementioned downside of the impedance mismatch between the """types""" in your config file format (how many bits wide is this integer? how much precision is this float? how is nullable data represented?) and the types in your actual language where it matters.
I never really felt like scheme got annoying when configuring guix. I’m half certain most of my configurations for Guix services were just yaml configs with s-expressions
I like the ability to introspect the system. I have a lua LSP, when I edit lua config files, I know all of the fields of the config I am editing, and I know how they behave (without randomly trying things)
Because it almost always devolves into that anyway. Every yaml system I have ever worked in winds up with some layer on top to “generate the yaml” or some other such madness.
In fact, that's how Lua itself came to be. They started with a simple configuration language and added more and more features until at some point they decided to rip the bandaid and turn it into a proper programming language.
> I have grown pretty negative opinions of “using a programming language as a config language”
Same here. I like the openbsd approach of small DSL (pf, doas) or just simple ini-like key-value config (sysctl, rc.conf). If you want more, just patch the software and be done with it.
A programming language is OK if the intent is to build a platform (Emacs, Vim) but for something that is purely an application software, it's very much not necessary.
>I have to ask…why do people want a Turing complete language to configure stuff?
because it lets me configure programmatically. Practical recent example, I use Wezterm which uses Lua as a config language but I tried out Ghostty and because I use all operating systems regularly I have a lot of 'if this then that' in my Wezterm config, different default shell, different key bindings etc. With Ghostty my only option is to maintain different config files per machine.
And what's worth pointing out is that Ghostty does have an operator for this('?' I think) which means there's already a bit of programming in it, except what always happens is that software with declarative config files invent their own scripting an templating languages as more and more people demand it, so just give me lua or lisp from the beginning and we're good.
> With Ghostty my only option is to maintain different config files per machine.
This turns out to be a benefit IMO.
Ghostty supports include files. You can have all of your shared config in 1 main config and then have small files that are included which are machine specific. My dotfiles uses it and it supports Linux and macOS. Example: https://github.com/nickjj/dotfriedrice/blob/master/.config/g...
You can have something like this in your Ghostty config: config-file = ?config.local
And then on each machine that's different, you can have your machine specific config in ~/.config/ghostty/config.local or whatever you decide to name the file.
It works out nicely because config options are merged, so the local file can overwrite what's in the main config. This lets you deviate from the original git committed config without needing to modify it. Super handy for public dotfiles.
A window manager / compositor is one of the few things where I can see this making a lot of sense. The alternative of using an IPC socket for everything would be more complex and require users to reinvent the wheel all the time. Also it makes low latency synchronous reactions to events really hard to implement well.
Seconded. Your configuration should be a simple declarative language with no Turing-complete escape hatches. Turing-complete configuration languages are the devil. That goes for build systems too: if you absolutely need Turing-completeness in your build system (my condolences for the hellscape you inhabit), use a separate task runner that does its arbitrary nonsense before dispatching to an underlying build system with declarative configuration.
I want a programming language as soon as the program benefits from conditional clauses or subsystems. So if the will and know-how is there, would be great to have it from the start.
I was pretty happy the day I could move some Jenkins jobs to a Groovy script. I've worked with HCL significantly, but once I learned the idiosyncrasies of Pulumi, scripting infrastructure via a programming language was a better experience (good IDE autocomplete simplified things), though it requires more discipline.
Even without working with the Nix scripting language I'll dismiss it. When I looked at it was some kind of bastardisation of Bash with Haskell ideas. A hobby project idea at best, yet forced upon all Nix users. Guile Scheme is a nice small language, and Guix uses that, and I think that is a better approach.
Nix isn't a scripting language in the sense you seem to have in mind. The snippets you saw that looked like Bash most likely were literally Bash, embedded as multiline strings in Nix.
I might be a good change but I left hyprland because,y configuration kept breaking. It's a good window manager so I'll change back once it gets stable. By now i3
I think the problem is with people downloading perfect configs from other people, I put the time to make my own, not overly complicated, basic window rules, nothing fancy. And it just werks, haven't changed it for 4 months (outside of rewriting it in lua, which took 30min and was quite fun).
My first hyprland experience was with ML4W (nothing against the guy) but as soon as you download it you get 10 config errors and you don't know where to begin.
I took the same philosophy as arch, I install only what I understand, and this way my config grew over time, my games where spawning in 2nd monitor? I look up manual and fix it, etc..
i'm mildly annoyed by the project in general because i put in a sizable effort getting the whole sway stack to cross compile correctly in nixpkgs/NixOS, keeping that stable for a year so that people could build on it, and then suddenly hyprland forked every package in the stack with a fresh set of "works on my machine" nix expressions, and then much of the peripheral sway packages (e.g. status bars like nwg-panel, notification centers, etc) decided to become dual-stack and take a dependency on those fast-moving/beta packages. for a solid month any time i updated my machine there was a _new_ hypr-something dependency in my sway desktop that broke cross compilation. eventually i gave up and just set `hyprland = null; hyprutils = null;` in my personal config: mainline's been broken for a year now, sorry to anyone who was using that.
it gives "rewrite it in rust" vibes in the way they rush in to re-do everything without understanding why things were the way they were or if, in fact, anyone was using that obscure feature. maybe they'll sort it all out in time; maybe not. wish they could at least take less of a "we don't care if we break your shit" attitude in the meantime.
Hyprland config break is usually syntax changes or reallocated features. Never had an instance where hyprland broke beyond repair or was hard to fix, even before LLMs were a thing. But yeah, its a 0.x software so if you aren't keen on fixing small stuff it's better to wait indeed. My point is that hyprland is easy to fix.
What you end up with is a config file that's natural to read with no prior knowledge about anything and if you want to look something specific up, you know it's officially documented and not some home grown pattern someone created. There's a certain amount of comfort and stability you get with a "what you see is what you get" approach.
I never felt like I needed variables, conditions, functions or loops with niri's config.
I wouldn't call KDL "established"; it's honestly pretty niche. It looks _similar_ to pre-existing configuration formats, but KDL is very picky about syntax. I.e.: single word string MUST be quoted.
In this same space, https://codeberg.org/emersion/scfg/ is pretty widely used. The curious thing about scfg is that it's not really a "new" format: the syntax described has been in use by different tools for decades. They just didn't call it scfg, and it's mostly the name itself that's new.
That's why I love qtile, written in python, modify everything in python, can import any module of it and can install anything, extend existing layout without forking to support very interesting and customized WM layouts, all entirely in python, call any python code in WM.
Lisp is the perfect family of languages for a config. Homoiconic for seamless config generation. S-expressions for shared human and machine readability.
Related to Lua - I've been maintaining this project that has Lua 5.1-5.5 in one Rust project [1]. The main reason to use it over mlua or the normal C Lua is for something that plays nicely with WASM/ general cross compilation or wants to support several different versions of Lua.
Seems like hyprland is on C++ so maybe not a direct use case but thought Lua people in general might be interested.
there are already converters online (i wrote a incomplete one as a neovim plugin for fun https://github.com/pynappo/hyprlang-to-lua.nvim) and reportedly LLMs work fine at it too. At the time i wrote my converter there was already a couple hundred configs i could search through on github to see what people did
I wonder how this would make Hyprland compare to Pinnacle or Awesome? So far I haven't found anything better than Awesome for crafting a bespoke desktop experience.
Uggghhh, I hate Lua. I hate the syntax, everything being tables, and.... dun dun dun 1-indexed arrays.
I wish we wouldn't keep going back to it. I understand the appeal for some use cases, but pleeeeeeease can we just move on to a new language that fulfills the same use cases but with more typical conventions?
Basically everything about this looks great - Rust-style syntax, static type checking, sane type system, easily embedded. The only slightly odd things are that it has built in types for IP addresses, AS numbers, and `filtermap`. But I guess you can just ignore those if you don't need them.
Then I won’t try! And I understand your opinion. But like everyone else I have many programs using many different configuration syntaxes, some using more than one file, some files in nonstandard locations, and some combining configuration from one or more files in my user directory with others somewhere in /etc or who knows where. I find the dwm approach refreshing.
Pontification added later: And it has a beneficial side-effect. I’m not much of a C programmer these days (if I ever was), but I found I was able to understand the dwm code well enough to make some small changes in behavior. So the dwm approach encouraged me to go beyond changing definitions in the headers. (This is aside from 3rd party patches. I was even able to contribute one of those.) This is really in the spirit of free software.
[delayed]
It's just part of what I call the config pendulum.
Simple config -> (Need to do more complicated things) -> Add override levels -> (Need even more flexibility) -> Add a Turing complete language -> (Things get ridiculous, lots of spaghetti code outside of version control. Time for a reset) -> goto "Simple config"
It's fine. I am not saying it's wrong or right. I've gone through the cycle a few times in some projects. On the other hand, think of it as your project is lucky to be used long enough to have these problems. To feel better about it think of it as a spiral. The next "Simple config" is a slightly better version of the first.
I've seen this expressed similarly as the 'configuration complexity clock': https://mikehadlow.blogspot.com/2012/05/configuration-comple...
I like your spiral metaphor though, since you learn some things along the way.
That's clever insight. If it was lisp from the beginning, maybe would be more straightforward. It's as simple as code can get, according to Uncle Bob, while still being expressive. It's no wonder Emacs still reigns supreme. Well, I am happy with Niri's kdl approach for the time being.
It can be Lisp if you want it to be. Just use Fennel. That's what my Hyprland config is written in.
I saw an interview with one of the main contributors for Neovim and they use fennel for everything. All roads lead to Lisp
I like to have a simple config AND a real scripting language. That way, the UX for changing "simple" things remains straightforward (you can even add a config editor panel), while for less simple things you can use a real programming language (reducing pressure from the "simple" config to turn into a DSL).
I haven't really seen program go back from "a programming language" to a simple config format.
Python setup.py -> pyproject.toml? Make -> ninja. eBPF kernel modules from C to a custom language. Helm Go templates -> Kustomize.
I am sure there are other projects picking up json from a previous xml + xpath + other ...xml junk.
> Make -> ninja
I would disagree on that one. Ninja config might not be turing complete, but they're generated by turing-complete tools (usually cmake). Nobody writes ninja by hand, thus I would argue it's irrelevant!
GN tool that is used in Chromium to generate ninja files has much more restrictive language than CMake or make. And even its more complex features are mostly workarounds or escape hatches to deal with legacy setups.
> Python setup.py -> pyproject.toml?
That's because setup.py was objectively a mistake. In order to know how to run the package you need to know its dependencies, which requires evaluating setup.py, but you cannot evaluate setup.py until you know the dependencies, which requires you to evaluate setup.py, and so on. The pyproject.toml is plain text where you specify the build backend and its options, and the build system can be as complex of a program as need by.
If anything, pyproject.toml is an example of taking the idea of programmable configuration to its next conclusion. The build system is part of the configuration and it's more than a simple script, it's an entire application. You just plug in its name into the universal entry point pyproject.toml.
Python went from setup.py to pyproject.toml, but pyproject.toml declares a build-system, which is another package which all the complex logic from setup.py.
Granted, it's a "simpler" config syntax, but the total system complexity has not decreased.
I'll die on the hill that Helm charts are more of a problem because text/templating is a weird looking templating language then anything else.
Or to be more specific, issue isn't text/templating as such. It is a fine templating language for text.
But to use a text templating language to generate YAML, which is not only structured, making it a bad match for character based templating with no knowledge of syntax, but indentation-based, making the combination almost seem like a joke.
Helm charts must be the worst engineering solution I have seen in popular use. First time I saw it I didn't believe it, that this was something people did, for real.
I wouldn't say text/template is terribly weird per se, and it's quite reminiscent of Jinja. But what is awful is using a text templating language to generate yaml with the correct level of indentation, and that's where 75% of Helm's problems lie; the other 25% is putting too much logic in templates while working with the clumsy workarounds to text/template having no capability of defining custom functions.
You actually can define custom functions as named templates, but they're definitely not pretty, and would almost certainly push you towards the "just allow us to write code using a normal programming language" side of the argument.
WirePlumber switched its config from Lua to a JSON variant not so long ago.
there's a rare form of that where it goes from( simple -> programming language -> language with DSL support -> simple dsl ) ; emacs has followed this model a bit.
Emacs seems to do a pretty good job handling this with the "Customize" interface. Presents a bunch of variables the user is intended to customise in something resembling a familiar interface, then it inserts the values into the Elisp init file. Someone could use and customise Emacs for years and never really touch Elisp directly. But then, oh, those text fields actually take lists, which in Emacs Lisp is the same as taking code. Maybe you use that for a while until you get comfortable and wanna try modifying something not surfaced in "customize", where you can discover init.el, etc. Etc. It's not perfect, but to me it's really close, it's the model of progression I wish all UIs for customisation used, personally.
I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying.
I have to ask…why do people want a Turing complete language to configure stuff? I use Sway personally, which is very configurable but for any even remotely complicated logic I shell out to a set of Rust programs.
If you look at hyprland config, you can see why they went with it.
Much like vim/neovim config, people want to do things like register a callback that fires to determine the window title and things that are much more advanced than that, like layout management.
When I was using sway, I was using its IPC or worse (https://github.com/johnae/persway) to do advanced things, and Lua scripting in the first class config would have been a much better UX.
It looks like the previous hyprland config language was already getting close to being Turing complete;
Already has variable substitution and math, it seems to falls short of Turing completeness only because I don't see any form of recursion. But recursion is something it could accidentally gain if someone decided to add templating to the language.
Besides, looks the config files can call out to external executables, which absolutely are Turing complete. And moving to lua might actually simplify configs by allowing more things to be done inside the config system, rather than calling out.
I did run Awesome for awhile and I liked it, but I never used the Lua config for the most trivial things so it never got in the way of anything.
I never found that Sway too annoying to just use the shell commands to grab/modify the current state of Sway (https://github.com/tombert/rs-swanbar) and just use a "real" programming language to actually do any kind of programming logic. To each their own!
That feels like a plugin or external program, not configuration
I have to agree. There are things that I want to do with my sway scratchpad that are just not possible because the config vocab is so limited. I might port my config to hyprland and give it a shot.
So you don't like using programming languages as config languages, so you:
1. Use a declarative-style format for config, which is fine, I guess; 2. ... and when that inevitably fails, you... use a programming language?
Some people -- not all, but some -- may prefer to skip the first step and go straight for the second option. Particularly if it's a complex thing indeed like a build system and not, y'know, configuring your blog.
The theoretical difference in power between a non-Turing complete declarative language and a turing complete one is irrelevant in practice. Datalog is a decidable, declarative subset of Turing-complete Prolog. It's also EXPTIME complete. I don't think we exclude any real use cases by prohibiting super-exponential algorithms.
The problem is shitty config languages. I wouldn't group xaml in the same category as dhall for example.
It's interesting because this is exactly what I used to do for my hyprland config (which the op is about). I had some keybinds that would shell out and use a script with the hyprctl cli.
Now it's all a single simple lua function and 3x as fast... I think this change is great.
Those aren't the only two options. There are non-Turing complete config languages like Cue, Dhall, and Jsonnet that are designed to complete and be consistent. They work well when did to generate static config from some dynamic input generated by regular program.
> 2. ... and when that inevitably fails, you... use a programming language?
Maybe it fails because you are trying to solve a problem with a configuration when it should be solved by a function implemented in the program you are trying to use.
> and when that inevitably fails
This assumption is doing a lot of work. Surely the question was precisely why it would fail?
It is good to keep a configuration simple enough that it doesn't need to be a programming language.
The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits. No need to end up contemplating some sort of for-loop macro with another key referencing the loop variable, when you can just have a for loop.
I find TOML, in addition to being very readable, to be great at automatically restricting config complexity by making nested lists of tables miserable. If your config sucks at being TOML, it should be JS or Python. (Not a fan of Lua.)
> The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits
That’s where you add a plugin system or an ipc mechanism, not a whole programming language.
python is terrible for embedding, starlark is the way to go. Very easy to embed.
Lua was specifically designed to be a configuration language https://www.lua.org/history.html
Lots of people start out with a non-programmable config format. But, as their situation becomes more complicated, they end up shoehorning in programmable-ish features until they realize they are running straight into https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule and decide to do it properly.
I mean, fair enough I guess. I've accidentally more-or-less reinvented interpreters on two separate occasions (both times using JSON as a quasi-AST), so I understand it.
I guess I just feel like if you feel like you need programming constructs in your configuration, its approaching it from the wrong angle, and it should instead be handled via plugins.
I feel like configuration itself should be a "dumb" format like JSON, and when you want to do anything that can't be accomplished by plain JSON, you should allow for easy development of plugins.
>and when you want to do anything that can't be accomplished by plain JSON
Like comments? ;)
YAML then, or something like it. I guess I just like dumb formats for this stuff.
Speaking personally, there are essentially two distinct reasons I like having programmable config languages:
- For personal application config (window manager, shell, text editor, etc), I find I often want to have site-specific configuration, but I also want identical configuration files at every workstation. My laptop probably needs slightly different keybindings than my desktop, my $PATH and text editor needs to be configured a bit differently for work than for personal use, etc. When the configuration is done with a real programming language, this is always straightforward, when it's done via a json/yml/toml file, it's usually a huge pain in the ass.
- You want templating for your configuration, to improve readability, reduce typos and configuration drift, &c, but if you give programmers an inch with any sort of templating system, they will eventually take a mile and figure out how to smuggle Turing-completeness (or, at least, for-loops and variable binding and probably closures) into their configs. If you have a real programming language, this is fine, because the programming language was designed to make loops and conditionals and function calls readable, and probably has decent tooling to boot, but if they're doing it with, say, Mustache-templated YAML, you will have an unreadable mess that is extremely unpleasant to work with.
The usual answer is "config macros", because if you don't give people something Turing complete they'll just m4 their way into Turing completeness and that isn't really an improvement. (Starlark in Bazel, etc.)
Half of me agrees with you. As someone who used to tinker with neovim all day I've had to learn just because you can program the problem doesn't mean you should and stick to a relatively minimal config.
Still, its a valid design choice with different design decisions compared to sway. But that's the point you get to choose.
Hyprland is much more "build your workspace with legos" so having a full lang like lua makes sense to properly integrate the various pieces.
All these window managers have a Turing complete configuration language, because you need to do things in response to events (keyboard hotkeys etc). It's just that for most of them, the "Turing completeness" happens through passing around strings with shell snippets. Might as well be a Lua callback function.
Because there's a never-ending stream of plausible use cases where it just missing one little option. Just look at the web: people have done all sorts of horrible stuff in Javascript to make up for missing HTML / CSS properties.
At a certain point it becomes incredibly tempting to just give up on playing whack-a-mole and let the most demanding users do it themselves using a proper programming language.
I have switched from FVWM to awesome because of Lua. Many years later, I have switched to i3 because it's not using a programming language for configuration. It's fine to have a configuration language if you have time to maintain, but your configuration can become quite complex and difficult to evolve. And it is also far more subject to breakage when upgrading.
I think I've found balance by using a Python daemon as a "companion" for my i3 configuration. It listens and react to event. It enhances the configuration, so when it's broken, it's not a big deal. And the interface exposed by i3 is smaller, so less risk of breakage. https://vincent.bernat.ch/en/blog/2021-i3-window-manager#i3-...
> I have to ask…why do people want a Turing complete language to configure stuff?
What's the alternative? Petition the maintainer to add every little feature any random user might want? Or just do it yourself in a few lines of code?
Case in point, when I was still using BSPWM I did no like how if there was only one window on the desktop it would still get an outline. So I wrote 14 lines of Awk (BSPWM lets you use any language) to get what I want. This was only possible because BSPWM gives me all the primitive building blocks and lets me go wild with them. Sure, if all you want to do is set a few colors and numbers that's overkill, but any power user will sooner or later find himself thinking "oh, if only I could do X when Y unless Z".
I think having good plugin support is a better way to do it. Keep the most obvious configuration options behind a "dumb" config language like JSON or something, but create a framework to add functionality via a plugin API.
> I have to ask…why do people want a Turing complete language to configure stuff?
I don't understand this either. IMO, the current SOTA tool for configuration is CUE, because it is the only one that lets you write schemas for arbitrary refinements. I haven't used it myself, but my understanding is that everybody should be writing configurations in something like this instead of YAML, TOML, HCL, or a custom DSL with no tooling. And yes, definitely not in a Turing complete programing language.
Cue is amazing, I'm using it to configure my kubernetes homelab.
I CANNOT imagine what horrors it would be to do it all with helm or templating.
> the current SOTA tool for configuration is CUE
the current state of the art tool for configuration is CUE (https://cuelang.org/). FTFY. Gotta love these acronyms.
I don't dislike it but I do think it's interesting that a number of minimalist WMs seem to have converged on the idea of code as config. I have used AwesomeWM for years and love its Lua configuration for providing infinite flexibility. When I was recently looking for something like AwesomeWM but in Wayland I toyed with the idea of moving to something with a simpler config format (and Hyprland was one of the options I considered). I can see the benefit of the simplicity but I guess for the kinds of users that use these WMs, maximum configurability probably trumps everything else. (Currently I am using SomeWM which is just an attempt to get something as close as possible to AwesomeWM in Wayland.)
Personally I have grown a bit frustrated with Lua as a language, but at the same time can see why it would be a good choice for this use case.
It smells like a variant of inner platform effect. Where in order to save you from programming the the config is super flexible, What is missed is that you are still programming only now you have to do it in some weird context.
At least in this case it is an actual programming language instead of XML or YAML like so many of them.
An alternative slightly more charitable interpretation is this is the engine/gamelogic pattern. But the difference between the two is more subtle than it naively appears depending largely on proper layer segmentation.
I would agree that turing-complete config is more trouble than it's worth when the config is something you might need to reason over, such as a build definition in Gradle. But for something like a window manager config where everyone's config is a snowflake, it's kind of ideal. Horses for courses and all that.
if you get into a config system that's complicated enough, and has modularization or inheritance, you'll know that the semantics of "remove this" "add that", override this, default to this, this stuff is hard to express in most config languages, or worse, you start enforcing application level semantics. when you have turing complete language you just ... do those things. we reduced the configuration data of a tool suite once by 90%+ by moving from json to python. there was a tremendous amount of duplication and overlap, with tons of TINY exceptions and variations. it was so hard to see those differences, brittle to maintain, things would get stale, ... moving to python you basically had the "base" thing expressed in one file, and a bunch of tiny delta files encoding the exact deviations. All those deviations were of the forms I described above. Adding a thing to a list. Removing a thign from a list. Overriding a whole list. Do a thing if not already done. And so on. It's also then easy to build all kinds of diagnostics, validators, etc, right into the same framework, without having to munge the data into some other form first.
It depends a lot on the config language. Gradle has the uncanny ability to be a "worst of both worlds" option, where there are not many upsides to its using a full language for its configuration. Build configuration is also a space where people and even some tooling seem to forget about good engineering practices, giving birth to fragile builds that people are afraid to modify and improve.
I think the progession is like 1) Oh, I can break stuff by changing a config value - it doesn't protect me. 2) Oh, I didn't think X would need to be configurable. 3) With code I can colocate the values with the code that uses them - easier to understand, and I can "configure" anything I want. 4) Why are we using configs?
Yeah I think there are two basic routes that work. Either you have a declarative configuration, or you go the route of Emacs and make the entire thing programmable.
Turing complete configuration languages suck and makes everything slow, janky and difficult to reason about.
I think INI-style config is one of the few good things that came out of the Microsoft/Windows ecosystem. Shame that it is so underspecified. We have TOML, of course, but I think for stupid config even that is too much.
The intersection of INI and TOML would be perfect.
TOML was created purely because INI has no format spec at all. So what you want is just TOML.
If you don't like certain things, just don't use them in your configs (i.e. tables)
What would you remove from TOML to make it perfect?
Tables.
Not from TOML, just from my config language. TOML has other applications that require its complexity.
I'd still keep simple INI style sections in my config lang, but they wouldn't have deeper meaning apart from grouping.
Tables in TOML have uniquely bad format
All scalar types other than strings (especially nonsense like datetimes). I'm already ingesting the configuration file as a string and parsing it into a language with actual types, e.g. Rust, and the act of parsing it into my defined configuration type will itself identify any problems with the config; having half-assed types like "int" in the config file format itself is not only useless, it's counterproductive because it requires people to ask questions like "okay, but what actually is the maximum range of integer values allowed to be contained in this type?". Just enforce UTF-8 encoded string values and let me take care of data validation.
The problem is that you end up with multiple dialects, just like INI.
For example, I’ve seen booleans being represented with “enable”/“disable”, “yes”/“no”, “t”/“f”, “1”/“0”. Sometimes a mix in the same program.
It’s nice that every TOML config requires “true”/“false” across any application.
You won't end up with a mix in the same program unless the code that you're using to parse the config is deliberately written to allow a mix, which no sane code owner would allow. And even if it did, that still wouldn't be enough to outweigh the aforementioned downside of the impedance mismatch between the """types""" in your config file format (how many bits wide is this integer? how much precision is this float? how is nullable data represented?) and the types in your actual language where it matters.
Isn't that called TOML?
An "intersection of INI and TOML" would presumably only have scalar values. TOML allows really complex lines like these:
I never really felt like scheme got annoying when configuring guix. I’m half certain most of my configurations for Guix services were just yaml configs with s-expressions
I like the ability to introspect the system. I have a lua LSP, when I edit lua config files, I know all of the fields of the config I am editing, and I know how they behave (without randomly trying things)
Because it almost always devolves into that anyway. Every yaml system I have ever worked in winds up with some layer on top to “generate the yaml” or some other such madness.
In fact, that's how Lua itself came to be. They started with a simple configuration language and added more and more features until at some point they decided to rip the bandaid and turn it into a proper programming language.
I think it's only really useful for things you'd want to be able to control programmatically, like text editors or in this case window managers
I fully agree with that.
Past experience has shown what while Turing complete config is powerful, it is also a double edged sword and I would be wary of using it.
The thing is that if your config language isn't Turing complete, the community will create N softwares to generate dynamic configs.
> I have grown pretty negative opinions of “using a programming language as a config language”
Same here. I like the openbsd approach of small DSL (pf, doas) or just simple ini-like key-value config (sysctl, rc.conf). If you want more, just patch the software and be done with it.
A programming language is OK if the intent is to build a platform (Emacs, Vim) but for something that is purely an application software, it's very much not necessary.
>I have to ask…why do people want a Turing complete language to configure stuff?
because it lets me configure programmatically. Practical recent example, I use Wezterm which uses Lua as a config language but I tried out Ghostty and because I use all operating systems regularly I have a lot of 'if this then that' in my Wezterm config, different default shell, different key bindings etc. With Ghostty my only option is to maintain different config files per machine.
And what's worth pointing out is that Ghostty does have an operator for this('?' I think) which means there's already a bit of programming in it, except what always happens is that software with declarative config files invent their own scripting an templating languages as more and more people demand it, so just give me lua or lisp from the beginning and we're good.
> With Ghostty my only option is to maintain different config files per machine.
This turns out to be a benefit IMO.
Ghostty supports include files. You can have all of your shared config in 1 main config and then have small files that are included which are machine specific. My dotfiles uses it and it supports Linux and macOS. Example: https://github.com/nickjj/dotfriedrice/blob/master/.config/g...
You can have something like this in your Ghostty config: config-file = ?config.local
And then on each machine that's different, you can have your machine specific config in ~/.config/ghostty/config.local or whatever you decide to name the file.
It works out nicely because config options are merged, so the local file can overwrite what's in the main config. This lets you deviate from the original git committed config without needing to modify it. Super handy for public dotfiles.
A window manager / compositor is one of the few things where I can see this making a lot of sense. The alternative of using an IPC socket for everything would be more complex and require users to reinvent the wheel all the time. Also it makes low latency synchronous reactions to events really hard to implement well.
Seconded. Your configuration should be a simple declarative language with no Turing-complete escape hatches. Turing-complete configuration languages are the devil. That goes for build systems too: if you absolutely need Turing-completeness in your build system (my condolences for the hellscape you inhabit), use a separate task runner that does its arbitrary nonsense before dispatching to an underlying build system with declarative configuration.
I want a programming language as soon as the program benefits from conditional clauses or subsystems. So if the will and know-how is there, would be great to have it from the start.
I was pretty happy the day I could move some Jenkins jobs to a Groovy script. I've worked with HCL significantly, but once I learned the idiosyncrasies of Pulumi, scripting infrastructure via a programming language was a better experience (good IDE autocomplete simplified things), though it requires more discipline.
Even without working with the Nix scripting language I'll dismiss it. When I looked at it was some kind of bastardisation of Bash with Haskell ideas. A hobby project idea at best, yet forced upon all Nix users. Guile Scheme is a nice small language, and Guix uses that, and I think that is a better approach.
Nix isn't a scripting language in the sense you seem to have in mind. The snippets you saw that looked like Bash most likely were literally Bash, embedded as multiline strings in Nix.
Nix doesn't have much in common with Haskell.
Nix is a really small language, and you can learn pretty much all of it in a few minutes: https://nixcloud.io/tour/?id=introduction/nix
Old news? 0.56 is out now https://hypr.land/news/update56/
I might be a good change but I left hyprland because,y configuration kept breaking. It's a good window manager so I'll change back once it gets stable. By now i3
I think the problem is with people downloading perfect configs from other people, I put the time to make my own, not overly complicated, basic window rules, nothing fancy. And it just werks, haven't changed it for 4 months (outside of rewriting it in lua, which took 30min and was quite fun).
My first hyprland experience was with ML4W (nothing against the guy) but as soon as you download it you get 10 config errors and you don't know where to begin. I took the same philosophy as arch, I install only what I understand, and this way my config grew over time, my games where spawning in 2nd monitor? I look up manual and fix it, etc..
It was my own config, I just felt annoying because a fundamental part of my system didn't work. I end upf fixing it later but it was veryannoying
i'm mildly annoyed by the project in general because i put in a sizable effort getting the whole sway stack to cross compile correctly in nixpkgs/NixOS, keeping that stable for a year so that people could build on it, and then suddenly hyprland forked every package in the stack with a fresh set of "works on my machine" nix expressions, and then much of the peripheral sway packages (e.g. status bars like nwg-panel, notification centers, etc) decided to become dual-stack and take a dependency on those fast-moving/beta packages. for a solid month any time i updated my machine there was a _new_ hypr-something dependency in my sway desktop that broke cross compilation. eventually i gave up and just set `hyprland = null; hyprutils = null;` in my personal config: mainline's been broken for a year now, sorry to anyone who was using that.
it gives "rewrite it in rust" vibes in the way they rush in to re-do everything without understanding why things were the way they were or if, in fact, anyone was using that obscure feature. maybe they'll sort it all out in time; maybe not. wish they could at least take less of a "we don't care if we break your shit" attitude in the meantime.
/rant
Hyprland config break is usually syntax changes or reallocated features. Never had an instance where hyprland broke beyond repair or was hard to fix, even before LLMs were a thing. But yeah, its a 0.x software so if you aren't keen on fixing small stuff it's better to wait indeed. My point is that hyprland is easy to fix.
same boat, tried hyprland and it's cool but seems a bit buggy, and switch back to i3 and settle there.
It's neat that Hyprland lets you define layouts in its config but I like niri's approach.
It uses KDL (an established document / config language) and slightly extends it to add useful things like being able to include files.
For example, here's mine: https://github.com/nickjj/dotfriedrice/blob/master/.config/n...
What you end up with is a config file that's natural to read with no prior knowledge about anything and if you want to look something specific up, you know it's officially documented and not some home grown pattern someone created. There's a certain amount of comfort and stability you get with a "what you see is what you get" approach.
I never felt like I needed variables, conditions, functions or loops with niri's config.
I wouldn't call KDL "established"; it's honestly pretty niche. It looks _similar_ to pre-existing configuration formats, but KDL is very picky about syntax. I.e.: single word string MUST be quoted.
In this same space, https://codeberg.org/emersion/scfg/ is pretty widely used. The curious thing about scfg is that it's not really a "new" format: the syntax described has been in use by different tools for decades. They just didn't call it scfg, and it's mostly the name itself that's new.
That's why I love qtile, written in python, modify everything in python, can import any module of it and can install anything, extend existing layout without forking to support very interesting and customized WM layouts, all entirely in python, call any python code in WM.
Lisp is the perfect family of languages for a config. Homoiconic for seamless config generation. S-expressions for shared human and machine readability.
Lua too. Neovim and Factorio come to mind first.
Related to Lua - I've been maintaining this project that has Lua 5.1-5.5 in one Rust project [1]. The main reason to use it over mlua or the normal C Lua is for something that plays nicely with WASM/ general cross compilation or wants to support several different versions of Lua.
Seems like hyprland is on C++ so maybe not a direct use case but thought Lua people in general might be interested.
[1] https://github.com/ianm199/omnilua
TIL I'm on 0.56 and hadn't realized there is a change.
Thinking I'll wait as long as I can and then just get an LLM to translate current config to lua once the internet has been seeded a bit with examples
there are already converters online (i wrote a incomplete one as a neovim plugin for fun https://github.com/pynappo/hyprlang-to-lua.nvim) and reportedly LLMs work fine at it too. At the time i wrote my converter there was already a couple hundred configs i could search through on github to see what people did
there is a converter: https://eiontusk.github.io/hyprlang2lua/
Nice. I'll give that a go. Pretty vanilla config so fair chance it'll work
I wonder how this would make Hyprland compare to Pinnacle or Awesome? So far I haven't found anything better than Awesome for crafting a bespoke desktop experience.
Uggghhh, I hate Lua. I hate the syntax, everything being tables, and.... dun dun dun 1-indexed arrays.
I wish we wouldn't keep going back to it. I understand the appeal for some use cases, but pleeeeeeease can we just move on to a new language that fulfills the same use cases but with more typical conventions?
I wish there was something better than Lua and just as "obvious" a choice. Static types, real arrays, zero-based indexing, etc.
Closest thing I've seen so far is Roto: https://roto.docs.nlnetlabs.nl/en/stable/index.html
Basically everything about this looks great - Rust-style syntax, static type checking, sane type system, easily embedded. The only slightly odd things are that it has built in types for IP addresses, AS numbers, and `filtermap`. But I guess you can just ignore those if you don't need them.
The language is primarily used by Rotonda, the composable, programmable BGP routing engine.
Not odd to have those data types at all…
Better to let specific domains define their own data types than favor one in the language.
This is kinda really old news at this point. 0.56 just came out.
I think dwm has the best approach to configuration: change the program and recompile.
This works for dwm because it compiles in two seconds and has minimal dependencies. I don’t know about hyprland.
https://dwm.suckless.org/customisation/
Requiring a C compiler, source code and header files to change your keybindings is just a different kind of bloat, and nothing can change my mind.
Then I won’t try! And I understand your opinion. But like everyone else I have many programs using many different configuration syntaxes, some using more than one file, some files in nonstandard locations, and some combining configuration from one or more files in my user directory with others somewhere in /etc or who knows where. I find the dwm approach refreshing.
Pontification added later: And it has a beneficial side-effect. I’m not much of a C programmer these days (if I ever was), but I found I was able to understand the dwm code well enough to make some small changes in behavior. So the dwm approach encouraged me to go beyond changing definitions in the headers. (This is aside from 3rd party patches. I was even able to contribute one of those.) This is really in the spirit of free software.
Auto play video when you scroll? Behave
Huh? This is from May. You guys should read the more recent notes. https://hypr.land/news/update56/
Nothing in those notes is interesting, but switching to Lua is. It doesn't matter that it happened a few weeks ago.
lua is love