The goal is to catch cases where the return value exists, but is
forgotten. There was a large enough number of them to turn this
into a real check. Initially, I just wanted to implement it to fix
the problems, then delete the code. But since this is so common, I
think it is worth the annoyance.
Since it is used only one, use require() directly. This allows
to require it from `beautiful` without a circular dependency.
In turn, this allows to set colors using the rules rather than
adding an endless amount of theme variables.
This commit introduce the new "ruled" module. This new top level
module will eventually host all "rules" related modules.
As for the content of the commit, it adds rules for notification. They
are mostly identical to the client rules and can be used to customize
or filter the notifications. It replaces the old "preset" API. The
preset API inner working was mostly a duplication of the early
`awful.rules` API, but was never as flexible. Thus the idea behind this
work is to converge all "core" classes to use a similar declarative API.
From now on, all core object will have their own rules. `awful.rules`
hardcodes some client specific code. All `rules` module have some form
of class specific code. This code will now be part of a new module
called `ruled`. Since a year or so, a lot of work has been done to
refactor the rules on top of the shared `gears.matcher` class. This way
there wont be as much duplication.
This has to be in its own commit otherwise Travis will fail. This
is because it will keep the file in the build directory when
iterating all commits. Then `ldoc` will fail because the file doesn't
have documentation. If `config.ld` is updated first, then it will
fail because `ruled/init.lua` doesn't exist yet. When it is done
in a separate commit, then `config.ld` is already updated and comes
with `init.lua`.
Emmanuel Lepage Vallee