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.
This removes the section about advanced build options and build
dependencies and points to the docs page instead.
Signed-off-by: Lucas Schwiderski <lucas@lschwiderski.de>
This converts the code snippets to the alternate block definition and
adds language hints to enable syntax highlighting for compatible parsers
(such as on the GitHub page).
Signed-off-by: Lucas Schwiderski <lucas@lschwiderski.de>
Some platforms, such as Arch Linux, already moved to Lua 5.4, while
offering Lua 5.3 as a separate executable, such as `/usr/bin/lua5.3`.
To be able to build awesomeWM on these platforms without extensive
shims, this change introduces a new CMake variable `LUA_EXECUTABLE`.
Its default is set by `find_program` to the usual `/usr/bin/lua`,
but allows running CMake like this:
```sh
cmake ../ \
-DLUA_INCLUDE_DIR=/usr/include/lua5.3 \
-DLUA_LIBRARY=/usr/lib/liblua.so.5.3 \
-DLUA_EXECUTABLE=/usr/bin/lua5.3
```
Emmanuel Lepage Vallee
Aire-One
mergify[bot]
Lucas Schwiderski
Lucas Schwiderski
Yauhen Kirylau
James R
Jonas Belouadi
Daniel Hahler