Output of awesome --version:
awesome v4.3-505-g0297bfff-dirty (Too long)
• Compiled against Lua 5.3.5 (running with Lua 5.3)
• D-Bus support: yes
• xcb-errors support: no
• execinfo support: yes
• xcb-randr version: 1.6
• LGI version: 0.9.2
How to reproduce the issue:
Error happens when opening something with a titlebar
Actual result:

Everytime i open something, it returns this error. I tried everything from now, installing many versions of Lua, Lua-lgi, building Awesome from git, installim from Awesome-git aur, and everytime this error appears. Help anyone?
Might be a regression due to recent changes
Finally had time to figure this one out. This turns out to be a behavior change in type detection. The previous code was silently discarding an invalid method input while the new code was "letting it fail because it should not happen". I will amend #2894 to ensure the old behavior is restored.
The is from the most popular (and amazing) AwesomeWM config ever on Reddit:
-- Padding
-- Only visible when equal padding is desired for the client
{
visible = user.anti_aliasing and equal_padding or only_borders,
buttons = user.anti_aliasing and only_borders and buttons,
bg = anti_aliasing_padding_color,
forced_height = anti_aliasing_padding,
widget = wibox.container.background
},
If I do:
print("\n\n\n\nHAS BUTTONS", user.anti_aliasing, only_borders, buttons, user.anti_aliasing and only_borders and buttons)
Then the result is false instead of nil. Because true and false and {} evaluates to a boolean, not "table or nil" like you might expect when using the or operator to do thing_a or thing_b or thing_c.
So the old code was silently rejecting the boolean buttons while the new code acts like most of Awesome and assume the type is right or let it print the error popup (and/or exception handler).
Most helpful comment
Finally had time to figure this one out. This turns out to be a behavior change in type detection. The previous code was silently discarding an invalid method input while the new code was "letting it fail because it should not happen". I will amend #2894 to ensure the old behavior is restored.
The is from the most popular (and amazing) AwesomeWM config ever on Reddit:
If I do:
Then the result is
falseinstead ofnil. Becausetrue and false and {}evaluates to a boolean, not "table or nil" like you might expect when using theoroperator to dothing_a or thing_b or thing_c.So the old code was silently rejecting the boolean buttons while the new code acts like most of Awesome and assume the type is right or let it print the error popup (and/or exception handler).