This was broken in commit c5202a4870 by adding an extra string
to the Lua stack. Hence, the offset -1 now referred to the string and
not the tag.
Fixes: https://github.com/awesomeWM/awesome/issues/3236
Signed-off-by: Uli Schlachter <psychon@znc.in>
When skimming over the source code, it might be easier for coders to see
what lua versions are supported, instead aren't. This doesn't have any
functional impact
Signed-off-by: Shay Agroskin <agrosshay@gmail.com>
Awesome doesn't support these versions. Preventing the project from
compiling with it saves the users some very frustrating and hard to
debug bugs.
The cmake version check is redundant with the version check in luaa.h.
Nevertheless, adding it allows to fail the project build sooner and
provides better user experience.
Fixes: #3324
Signed-off-by: Shay Agroskin <agrosshay@gmail.com>
Add an explicite `@property` tag to the `wibox.layout.flex` doc
comments to override the `fill_space` property from
`wibox.layout.fixed` and mark it as hidden thanks to `@hidden`.
For some even more strange reasons than commit 047729ae1, it seems
we can also have the error that `item.inherited` can be sets to `true`
on items that are not inherited...
I just had this issue with `wibox.widget.imagebox` where properties
were marked as inherited from `wibox.widget.imagebox`. Best way to fix
it is to only trust the check on `item.baseclass`, and completly
dismiss its `inherited` property.
Add a new ldoc tag `@hidden`. This tag allows us to keep documentation
for magic methods (e.g. `wibox.widget.base:get_visible`) but prevent
it from being part of the documentation used by final users.
For some reasons, sometime `item.inherited` is `false` even if the
item was added to the `all_module_kinds` table by the "hierarchy
lookup" for-loop, and we already force the `inherited` property to be
sets to `true` at this moment.
With this commit, we add a second fail-check condition based on the
`item.baseclass` property to determine if the item is inherited or not
when we do the render.
This commit adds a new ldoc custom tag `@supermodule`. It has to be
used at the module level. It should refer to the module
supermodules.
This tag can be used multiple time by the same module, but we ignore
other calls (for now?) as (AFAIK) we only use one way inheritance.
This tag is used in the ldoc template to find modules hierarchy and
draw the inheritance tree. It makes it easy to find and navigate to
parents modules.
mergify[bot]
Uli Schlachter
actionless
Emmanuel Lepage Vallee
ShayAgros
Shay Agroskin
Shay Agroskin
Aire-One
Aire-One
Lucas Schwiderski