awesomewm-mirrors
/
vicious
mirror of https://github.com/vicious-widgets/vicious.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

[docs] Create symlinks to CONTRIBUTING and CHANGELOG

This commit is contained in:
Nguyễn Gia Phong 2020-09-13 17:35:11 +07:00
parent d35eeb2ed3
commit 365e754d8d
9 changed files with 295 additions and 249 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

136
CHANGELOG.rst Normal file
View File

@ -0,0 +1,136 @@
Changelog
=========
Changes in 2.5.0 (WIP)
----------------------
Changes in 2.4.2
----------------
Feature: [hwmontemp] Bring back sysfs path cache
Changes in 2.4.1
----------------
Fixed:
- [pkg] Fallback the number of lines before packages listing to 0.
This fixes crashes on Arch, FreeBSD and Mandriva.
- [mdir] Remove trailing semicolon at the end of command.
Changes in 2.4.0
----------------
.. important::
``volume`` now uses 🔉 and 🔈 instead of ♫ and ♩ to show mute state.
This BREAKS backward compatibility if users substitute custom symbols
from these default.
Added:
- notmuch_all, cpu_freebsd widget types.
- [cmus_all] Promote to ``widgets/``.
- [wifiiw_linux] Expose BSSID.
- [wifi_linux] Expose frequency and transmission power.
- ``spawn`` as a fallback for ``awful.spawn`` in case Vicious is used as
a stand-alone library. This wrapper, however, does NOT provide the facilities
to asynchronously spawn new processes. It also lacks a few features such as
parsing ``stderr`` and returning PID.
- ``helpers.setasyncall`` to avoid writing redundant workers for asynchronous
widget types. Note that these workers are only needed in case Vicious is used
as a stand-alone library.
- ``helpers.setcall`` for registering functions as widget types.
- ``headergen`` script for automatic generation of copyright notices.
- ``templates`` for the ease of adding new widget types.
- ``CONTRIBUTING.md`` which guide contributors through the steps
of filing an issue or submitting a patch.
Fixed:
- Deprecate the use of ``io.popen`` in following widgets:
- wifi_linux, wifiiw_linux, hwmontemp_linux, hddtemp_linux
- bat_freebsd, mem_freebsd, net_freebsd, thermal_freebsd, uptime_freebsd,
- cpu_freebsd, cpufreq_freebsd, fanspeed_freebsd
- bat_openbsd
- volume, gmail, mdir, mpd, fs
- [mpd] Lua 5.3 compatibility (for real this time); also correct a typo
- [mbox] Update the deprecated ``string.gfind`` to ``string.gmatch``
- [pkg,weather,contrib/btc] Allow function call without Awesome
- [pkg] Use more updated front-ends for Debian/Ubuntu (apt) and Fedora (dnf)
- [os] Splitted os_all into os_linux and os_bsd (and refactored to async)
- Tweak ``.luacheckrc`` to suit functional style and soft-limit text width to 80
- Update copyright headers for libraries and widget types
Removed:
- ``helpers.sysctl`` and ``helpers.sysctl_table`` were removed in favour of
``helpers.sysctl_async``.
Changes in 2.3.3
----------------
Feature: Add battery widget type for OpenBSD
Fixes:
- [mpd] Lua 5.3 compatibility
- [bat_freebsd] Update battery state symbols
Changes in 2.3.2
----------------
Features:
- Support stacked graphs
- [hwmontemp_linux] Provide name-based access to hwmon sensors via sysfs
- [mpd_all] Expose more informations and format time in [hh:]mm:ss
Fixes:
- Improve defaults and mechanism for data caching
- Escape XML entities in results by default
- [weather_all] Update NOAA link and use Awesome asynchronous API
- [mem_linux] Use MemAvailable to calculate free amount
- [mem_freebsd] Correct calculation and switch to swapinfo for swap
- [bat_freebsd] Add critical charging state
- [fs_all] Fix shell quoting of option arguments
Moreover, ``.luacheckrc`` was added and ``README.md`` was refomatted
for the ease of development.
Changes in 2.3.1
----------------
Fixes:
- widgets can be a function again (regression introduced in 2.3.0)
Changes in 2.3.0
----------------
Features:
- add btc widget
- add cmus widget
- alsa mixer also accept multiple arguments
Fixes:
- pkg now uses non-blocking asynchronous api
Changes in 2.2.0
----------------
Notable changes:
- moved development from git.sysphere.org/vicious to github.com/Mic92/vicious
- official freebsd support
- escape variables before passing to shell
- support for gear timers
- fix weather widget url
- add :lua:func:`vicious.call` method to obtain data outside of widgets
For older versions please see ``git log``.

174
CONTRIBUTING.md → CONTRIBUTING.rst
View File

@ -1,6 +1,8 @@
# How to contribute to Vicious Contribution Guidelines
=======================
## Filing an Issue Filing an Issue
---------------
* Ensure the bug was not already reported by searching GitHub Issues. * Ensure the bug was not already reported by searching GitHub Issues.
* If you're unable to find an open issue addressing the problem, * If you're unable to find an open issue addressing the problem,
@ -15,9 +17,11 @@ Please re-read your issue once again to avoid a couple of common mistakes
* Is the description of the issue itself sufficient? * Is the description of the issue itself sufficient?
Make sure that it's obvious Make sure that it's obvious
- What the problem is
- How it could be fixed * What the problem is
- How your proposed solution would look like * How it could be fixed
* How your proposed solution would look like
* Have you provide the versions of Vicious and related software? * Have you provide the versions of Vicious and related software?
We would like to how you installed Vicious, which OS you're using, We would like to how you installed Vicious, which OS you're using,
the version of the software or what kind of hardware you are trying the version of the software or what kind of hardware you are trying
@ -34,85 +38,87 @@ Please re-read your issue once again to avoid a couple of common mistakes
Do not post features because they seem like a good idea. Do not post features because they seem like a good idea.
If they're really useful, they'll be requested by someone who requires them. If they're really useful, they'll be requested by someone who requires them.
## Requesting for Merging a Patch Requesting for Merging a Patch
------------------------------
1. [Fork this repository](https://github.com/vicious-widgets/vicious/fork) #. `Fork this repository`_
2. Check out the source code with: #. Check out the source code with::
git clone https://github.com/YOUR_GITHUB_USERNAME/vicious.git git clone https://github.com/YOUR_GITHUB_USERNAME/vicious.git
cd vicious cd vicious
3. Start working on your patch. If you want to add a new widget type, #. Start working on your patch. If you want to add a new widget type,
see the `templates` directory for a more detailed guide. see the ``templates`` directory for a more detailed guide.
4. Have a look at `helpers.lua` and `spawn.lua` for possible helper functions. #. Have a look at ``helpers.lua`` and ``spawn.lua``
5. Make sure your code follows the coding conventions below and check the code for possible helper functions.
with `luacheck`. This *should fail* at first, but you can continually #. Make sure your code follows the coding conventions below and check the code
re-run it until you're done. with ``luacheck``. This *should fail* at first, but you can continually
re-run it until you're done::
luacheck --config .luacheckrc . luacheck --config tools/luacheckrc .
6. Make sure your code works under all Lua versions claimed supported #. Make sure your code works under all Lua versions claimed supported
by Vicious, namely 5.1, 5.2 and 5.3. by Vicious, namely 5.1, 5.2 and 5.3.
7. Update the copyright notices of the files you modified. Vicious is #. Update the copyright notices of the files you modified. Vicious is
collectively licensed under GPLv2+, and to protect the freedom of the users, collectively licensed under GPLv2+, and to protect the freedom of the users,
copyright holders need to be properly documented. copyright holders need to be properly documented.
8. Try to note your changes under `Changes.md`. If you find it is #. Try to note your changes under ``CHANGELOG.rst``. If you find it is
difficult to phrase the changes, you can leave it for us. difficult to phrase the changes, you can leave it for us.
9. [Add](https://git-scm.com/docs/git-add) the changes, #. Add_ the changes, commit_ them and push_ the result, like this::
[commit](https://git-scm.com/docs/git-commit) them
and [push](https://git-scm.com/docs/git-push) the result, like this:
git add widgets/bar_baz.lua README.md git add widgets/bar_baz.lua README.md
git commit -m '[bar_baz] Add widget type' git commit -m '[bar_baz] Add widget type'
git add helpers.lua Changes.md git add helpers.lua CHANGELOG.rst
git commit -m '[helpers] Fix foo' git commit -m '[helpers] Fix foo'
git push git push
10. Finally, [create a pull request](https://help.github.com/articles/creating-a-pull-request). #. Finally, `create a pull request`_. We'll then review and merge it.
We'll then review and merge it.
In any case, thank you very much for your contributions! In any case, thank you very much for your contributions!
## Coding Conventions Coding Conventions
------------------
This section introduces a guideline for writing idiomatic, robust This section introduces a guideline for writing idiomatic, robust
and future-proof widget type code. and future-proof widget type code.
### Whitespace in Expressions and Statements Whitespace in Expressions and Statements
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Avoid extraneous whitespace in the following situations: Avoid extraneous whitespace in the following situations:
* Immediately inside parentheses or brackets. Braces, however, are exceptions * Immediately inside parentheses or brackets. Braces, however, are exceptions
to this rule: to this rule:
```lua .. code-block:: lua
foo(bar[1], { baz = 2 }) -- yes foo(bar[1], { baz = 2 }) -- yes
foo( bar[ 1 ], {baz = 2} ) -- no foo( bar[ 1 ], {baz = 2} ) -- no
```
* Immediately before a comma, semicolon, or colon. * Immediately before a comma, semicolon, or colon.
* Immediately before the open parenthesis, braces, quote, etc. * Immediately before the open parenthesis, braces, quote, etc.
that starts the argument list of a function call; or the open bracket that starts the argument list of a function call; or the open bracket
that starts an indexing. In other words, prefer these: that starts an indexing. In other words, prefer these:
```lua .. code-block:: lua
foo(bar, baz) foo(bar, baz)
foo{ bar, baz } foo{ bar, baz }
foo"bar" foo"bar"
foo[[bar]] foo[[bar]]
foo[bar] foo[bar]
```
* Trailing at the end of line or (newline) at the end of file. * Trailing at the end of line or (newline) at the end of file.
Always surround these binary operators with a single space on either side: Always surround these binary operators with a single space on either side:
assignment (`=`), comparisons, Booleans (`and`, `or`, `not`). assignment (``=``), comparisons, Booleans (``and``, ``or``, ``not``).
If operators with different priorities are used, consider adding whitespace If operators with different priorities are used, consider adding whitespace
around the operators with the lowest priorities. Use your own judgment; around the operators with the lowest priorities. Use your own judgment;
however, never use more than one space, and always have however, never use more than one space, and always have
the same amount of whitespace on both sides of a binary operator. the same amount of whitespace on both sides of a binary operator.
### Indentation Indentation
^^^^^^^^^^^
Use 4 *spaces* per indentation level. Use 4 *spaces* per indentation level.
@ -122,7 +128,8 @@ inside parentheses, brackets and braces, or using a hanging indent
non-whitespace character of the line, with subsequent lines being indented non-whitespace character of the line, with subsequent lines being indented
until the closing parenthesis), e.g. until the closing parenthesis), e.g.
```lua .. code-block:: lua
-- Vertically aligned -- Vertically aligned
long_function_call{ foo, bar, long_function_call{ foo, bar,
baz } baz }
@ -131,17 +138,16 @@ long_function_call{ foo, bar,
long_function_call( long_function_call(
foo, bar foo, bar
baz) baz)
```
The closing brace or bracket on multi-line constructs may either line up under The closing brace or bracket on multi-line constructs may either line up under
the first character of the line that starts the construct, as in: the first character of the line that starts the construct, as in:
```lua .. code-block:: lua
long_function_call{ long_function_call{
foo = 1, bar = 2, foo = 1, bar = 2,
baz = 3, baz = 3,
} }
```
In this case, and this case only, the trailing comma is acceptable In this case, and this case only, the trailing comma is acceptable
to avoid diff noises when more values are added, to avoid diff noises when more values are added,
@ -150,19 +156,21 @@ it's occasionally helpful to do so.
Trailing right parentheses, however, are not allowed. Trailing right parentheses, however, are not allowed.
### Maximum Line Length Maximum Line Length
^^^^^^^^^^^^^^^^^^^
If possible, try to limit all *code* lines to a maximum If possible, try to limit all *code* lines to a maximum
of 80 characters. In case you find some lines in your patch would be of 80 characters. In case you find some lines in your patch would be
more readable exceeding this limit, feel free to discuss with us. more readable exceeding this limit, feel free to discuss with us.
Comments and long strings need not to follow this restriction however. Comments and long strings need not to follow this restriction however.
As one might have noticed, the syntactic sugars `f{<fields>}` As one might have noticed, the syntactic sugars ``f{<fields>}``
(for `f({<fields>})`) and `f'<string>'` (or `f"<string>"`/`f[[<string>]]`, (for ``f({<fields>})``) and ``f'<string>'``
for `f('<string>')`) are especially preferred to squeeze (or ``f"<string>"``/``f[[<string>]]``, for ``f('<string>')``)
the line length to this limit. are especially preferred to squeeze the line length to this limit.
### Blank Lines Blank Lines
^^^^^^^^^^^
Surround function definitions with a single blank line. Extra blank lines Surround function definitions with a single blank line. Extra blank lines
may be used (sparingly) to separate groups of related functions. may be used (sparingly) to separate groups of related functions.
@ -170,12 +178,13 @@ Blank lines may be omitted between a bunch of related one-liners
(e.g. a set of dummy implementations). (e.g. a set of dummy implementations).
Use blank lines in functions, sparingly, to indicate logical sections. Use blank lines in functions, sparingly, to indicate logical sections.
### Requiring Libraries Requiring Libraries
^^^^^^^^^^^^^^^^^^^
All standard libraries should be localized before used All standard libraries should be localized before used
for the matter of performance. for the matter of performance.
`require`s should always be put at the top of the source file, ``require``'s should always be put at the top of the source file,
just after the copyright header, and before module globals and constants, just after the copyright header, and before module globals and constants,
and grouped in the following order: and grouped in the following order:
@ -185,50 +194,54 @@ and grouped in the following order:
For example, For example,
```lua .. code-block:: lua
local type = type local type = type
local table = { concat = table.concat, insert = table.insert } local table = { concat = table.concat, insert = table.insert }
local awful = require("awful") local awful = require("awful")
local helpers = require("vicious.helpers") local helpers = require("vicious.helpers")
```
### String Quotes String Quotes
^^^^^^^^^^^^^
In Lua, single-quoted strings and double-quoted strings are the same, In Lua, single-quoted strings and double-quoted strings are the same,
so the choice is totally up to you, but please be consistent within a module. so the choice is totally up to you, but please be consistent within a module.
When a string contains single or double quote characters, however, When a string contains single or double quote characters, however,
use the other one to avoid backslashes in the string. It improves readability: use the other one to avoid backslashes in the string. It improves readability:
```lua .. code-block:: lua
'"key": "value"' -- good '"key": "value"' -- good
"\"key\": \"value\"" -- no good "\"key\": \"value\"" -- no good
```
It is preferable to add a newline immediately after the opening long bracket: It is preferable to add a newline immediately after the opening long bracket:
```lua .. code-block:: lua
foo = [[ foo = [[
this is a really, this is a really,
really, really,
really long text]] really long text]]
```
### Naming Conventions Naming Conventions
^^^^^^^^^^^^^^^^^^
Avoid using the characters `l` (lowercase letter el), `O` (uppercase letter oh), Avoid using the characters ``l`` (lowercase letter el),
or `I` (uppercase letter eye) as single character variable names. ``O`` (uppercase letter oh), or ``I`` (uppercase letter eye)
In some fonts, these characters are indistinguishable from the 1's and 0's. as single character variable names. In some fonts, these characters
are indistinguishable from the 1's and 0's.
#### Constants Constants
"""""""""
Constants are usually defined on a module level Constants are usually defined on a module level
and written in all capital letters with underscores separating words. and written in all capital letters with underscores separating words.
Examples include `MAX_OVERFLOW` and `TOTAL`. Examples include ``MAX_OVERFLOW`` and ``TOTAL``.
Function and Variable Names
#### Function and Variable Names """""""""""""""""""""""""""
Function names should be lowercase, with words separated by underscores Function names should be lowercase, with words separated by underscores
as necessary to improve readability. as necessary to improve readability.
@ -238,7 +251,8 @@ Variable names follow the same convention as function names.
When you find it difficult to give descriptive names, When you find it difficult to give descriptive names,
use the functions and variable anonymously. use the functions and variable anonymously.
### Performance Tips Performance Tips
^^^^^^^^^^^^^^^^
Vicious is meant to be run as part of the Awesome window manager, Vicious is meant to be run as part of the Awesome window manager,
thus any little overhead may defect the responsiveness of the UI. thus any little overhead may defect the responsiveness of the UI.
@ -258,7 +272,8 @@ However, declare a variable only when you need it, to avoid declaring it
without an initial value (and therefore you seldom forget to initialize it). without an initial value (and therefore you seldom forget to initialize it).
Moreover, you shorten the scope of the variable, which increases readability. Moreover, you shorten the scope of the variable, which increases readability.
### Copyright Header Copyright Header
^^^^^^^^^^^^^^^^
Vicious is released under the GNU GNU General Public License Vicious is released under the GNU GNU General Public License
version 2 or later and each contributor holds the copyright version 2 or later and each contributor holds the copyright
@ -266,7 +281,8 @@ on their contributions. To make this collective control effective,
each source file must include a notice of the following format each source file must include a notice of the following format
denoting the name of all authors denoting the name of all authors
```lua .. code-block:: lua
-- <one line to give the program's name and a brief idea of what it does.> -- <one line to give the program's name and a brief idea of what it does.>
-- Copyright (C) <year> <name of author> <<email that can be use for contact>> -- Copyright (C) <year> <name of author> <<email that can be use for contact>>
-- --
@ -284,9 +300,9 @@ denoting the name of all authors
-- --
-- You should have received a copy of the GNU General Public License -- You should have received a copy of the GNU General Public License
-- along with Vicious. If not, see <https://www.gnu.org/licenses/>. -- along with Vicious. If not, see <https://www.gnu.org/licenses/>.
```
### Comments Comments
^^^^^^^^
Comments that contradict the code are worse than no comments. Comments that contradict the code are worse than no comments.
Always make a priority of keeping the comments up-to-date when the code changes! Always make a priority of keeping the comments up-to-date when the code changes!
@ -294,25 +310,35 @@ Always make a priority of keeping the comments up-to-date when the code changes!
You should use two spaces after a sentence-ending period You should use two spaces after a sentence-ending period
in multi-sentence comments, except after the final sentence. in multi-sentence comments, except after the final sentence.
#### Block Comments Block Comments
""""""""""""""
Block comments generally apply to some (or all) code that follows them, Block comments generally apply to some (or all) code that follows them,
and are indented to the same level as that code. Each line of a block comment and are indented to the same level as that code. Each line of a block comment
starts with `--` and a single space, unless text inside the comment is indented, starts with ``--`` and a single space, unless text inside the comment
or it is to comment out code. is indented, or it is to comment out code.
Paragraphs inside a block comment are separated by a line containing `--` only. Paragraphs inside a block comment are separated by a line containing
The best example is the copyright notice in the section above. ``--`` only. The best example is the copyright notice in the section above.
The `--[[...]]` style may only be used for commenting out source code. The ``--[[...]]`` style may only be used for commenting out source code.
#### Inline Comments Inline Comments
"""""""""""""""
An inline comment is a comment on the same line as a statement. An inline comment is a comment on the same line as a statement.
Inline comments should be separated by at least two spaces from the statement. Inline comments should be separated by at least two spaces from the statement.
They should start with `-- `. They should start with ``--`` and one single space.
## Influences Influences
----------
These contributing guideline are heavily influenced by that of `youtube-dl`, These contributing guideline are heavily influenced by that of ``youtube-dl``,
PEP 8, Programming in Lua and the performance tips in Lua Programming Gems. PEP 8, Programming in Lua and the performance tips in Lua Programming Gems.
.. _Fork this repository: https://github.com/vicious-widgets/vicious/fork
.. _Add: https://git-scm.com/docs/git-add
.. _commit: https://git-scm.com/docs/git-commit
.. _push: https://git-scm.com/docs/git-push
.. _create a pull request:
https://help.github.com/articles/creating-a-pull-request

119
Changes.md
View File

@ -1,119 +0,0 @@
# Changes in 2.4.2
Feature: [hwmontemp] Bring back sysfs path cache
# Changes in 2.4.1
Fixed:
- [pkg] Fallback the number of lines before packages listing to 0.
This fixes crashes on Arch, FreeBSD and Mandriva.
- [mdir] Remove trailing semicolon at the end of command.
# Changes in 2.4.0
IMPORTANT:
- `volume` now uses 🔉 and 🔈 instead of ♫ and ♩ to show mute state.
This BREAKS backward compatibility if users substitute custom symbols
from these default.
Added:
- notmuch_all, cpu_freebsd widget types.
- [cmus_all] Promote to `widgets/`.
- [wifiiw_linux] Expose BSSID.
- [wifi_linux] Expose frequency and transmission power.
- `spawn` as a fallback for `awful.spawn` in case Vicious is used as
a stand-alone library. This wrapper, however, does NOT provide the facilities
to asynchronously spawn new processes. It also lacks a few features such as
parsing `stderr` and returning PID.
- `helpers.setasyncall` to avoid writing redundant workers for asynchronous
widget types. Note that these workers are only needed in case Vicious is used
as a stand-alone library.
- `helpers.setcall` for registering functions as widget types.
- `headergen` script for automatic generation of copyright notices.
- `templates` for the ease of adding new widget types.
- `CONTRIBUTING.md` which guide contributors through the steps
of filing an issue or submitting a patch.
Fixed:
- Deprecate the use of `io.popen` in following widgets:
* wifi_linux, wifiiw_linux, hwmontemp_linux, hddtemp_linux
* bat_freebsd, mem_freebsd, net_freebsd, thermal_freebsd, uptime_freebsd,
cpu_freebsd, cpufreq_freebsd, fanspeed_freebsd
* bat_openbsd
* volume, gmail, mdir, mpd, fs
- [mpd] Lua 5.3 compatibility (for real this time); also correct a typo
- [mbox] Update the deprecated `string.gfind` to `string.gmatch`
- [pkg,weather,contrib/btc] Allow function call without Awesome
- [pkg] Use more updated front-ends for Debian/Ubuntu (apt) and Fedora (dnf)
- [os] Splitted os_all into os_linux and os_bsd (and refactored to async)
- Tweak `.luacheckrc` to suit functional style and soft-limit text width to 80
- Update copyright headers for libraries and widget types
Removed:
- `helpers.sysctl` and `helpers.sysctl_table` were removed in favour of
`helpers.sysctl_async`.
# Changes in 2.3.3
Feature: Add battery widget type for OpenBSD
Fixes:
- [mpd] Lua 5.3 compatibility
- [bat\_freebsd] Update battery state symbols
# Changes in 2.3.2
Features:
- Support stacked graphs
- [hwmontemp\_linux] Provide name-based access to hwmon sensors via sysfs
- [mpd\_all] Expose more informations and format time in [hh:]mm:ss
Fixes:
- Improve defaults and mechanism for data caching
- Escape XML entities in results by default
- [weather\_all] Update NOAA link and use Awesome asynchronous API
- [mem\_linux] Use MemAvailable to calculate free amount
- [mem\_freebsd] Correct calculation and switch to swapinfo for swap
- [bat\_freebsd] Add critical charging state
- [fs\_all] Fix shell quoting of option arguments
Moreover, `.luacheckrc` was added and `README.md` was refomatted for the ease
of development.
# Changes in 2.3.1
Fixes:
- widgets can be a function again (regression introduced in 2.3.0)
# Changes in 2.3.0
Features:
- add btc widget
- add cmus widget
- alsa mixer also accept multiple arguments
Fixes:
- pkg now uses non-blocking asynchronous api
# Changes in 2.2.0
Notable changes:
- moved development from git.sysphere.org/vicious to github.com/Mic92/vicious
- official freebsd support
- escape variables before passing to shell
- support for gear timers
- fix weather widget url
- add vicious.call() method to obtain data outside of widgets
For older versions see git log

9
README.md
View File

@ -12,12 +12,10 @@ timers, suspend widgets and so on. Vicious doesn't depend on any third party
Lua libraries, but may depend on additional system utilities (see widget Lua libraries, but may depend on additional system utilities (see widget
description). description).
## Contributing ## Usage
For details, see CONTRIBUTING.md. Vicious is licensed under GNU GPLv2+, Please see our [online documentation] for detail instructions.
which require all code within the package to be released under It is also available under the `docs` directory for offline reference.
a compatible license. All contributors retain their copyright to their code,
so please make sure you add your name to the header of every file you touch.
## Copying ## Copying
@ -28,4 +26,5 @@ License, or (at your option) any later version.
Please refer to our documentation for the full [list of authors]. Please refer to our documentation for the full [list of authors].
[online documentation]: https://vicious.rtfd.io
[list of authors]: https://vicious.rtfd.io/copying.html [list of authors]: https://vicious.rtfd.io/copying.html

1
docs/source/changelog.rst Symbolic link
View File

@ -0,0 +1 @@
../../CHANGELOG.rst

1
docs/source/contributing.rst Symbolic link
View File

@ -0,0 +1 @@
../../CONTRIBUTING.rst

2
docs/source/index.rst
View File

@ -26,7 +26,9 @@ Table of Contents
format format
caching caching
security security
contributing
copying copying
changelog
See Also See Also
-------- --------

0
headergen → tools/headergen
View File

0
.luacheckrc → tools/luacheckrc
View File