feat: add --help

[lewis6991]

Content copied from https://luals.github.io/wiki/usage/

Preview

./bin/lua-language-server --help
--socket=<value>

    Will communicate to a client over the specified TCP port instead of through stdio.

    Type: number

    Example: --socket=5050

--develop

    Enables development mode. This allows plugins to write to the logpath.

    Type: boolean

--force-accept-workspace

    Allows the use of root/home directory as the workspace.

    Type: boolean

--configpath=<value>

    The location of the configuration file that will be loaded.
    Can be relative to the workspace.
    When provided, config files from elsewhere (such as from VS Code) will no longer be loaded.

    Type: string

    Example: --configpath=sumnekoLuaConfig.lua

--loglevel=<value>

    The minimum level of logging that should appear in the logfile.
    Can be used to log more detailed info for debugging and error reporting.
    Options:
    - error
    - warn
    - info
    - debug
    - trace

    Type: string

    Example: --loglevel=trace

--checklevel=<value>

    To be used with --check. The minimum level of diagnostic that should be logged.
    Items with lower priority than the one listed here will not be written to the file.
    Options include, in order of priority:
    - Error
    - Warning
    - Information
    - Hint

    Type: string

    Default: Warning

    Example: --checklevel=Information

--help=<value>

    Print this message.

--metapath=<value>

    Where the standard Lua library definition files should be generated to.

    Type: string

    Default: ./meta

    Example: --metapath=D:/sumnekoLua/metaDefintions

--check_format=<value>

    Output format for the check results.
    - 'pretty': results are displayed to stdout in a human-readable format.
    - 'json': results are written to a file in JSON format. See --check_out_path

    Type: json, pretty

    Default: pretty

--logpath=<value>

    Where the log should be written to.

    Type: string

    Default: ./log

    Example: --logpath=D:/luaServer/logs

--check=<value>

    Perform a "diagnosis report" where the results of the diagnosis are written to the logpath.

    Type: string

    Example: --check=C:\Users\Me\path\to\workspace

--version=<value>

    Get the version of the Lua language server.
    This will print it to the command line and immediately exit.

    Type: string

--doc=<value>

    Generate documentation from a workspace.
    The files will be output in your log path.

    Type: string

    Example: --doc=C:/Users/Me/Documents/myLuaProject/

--locale=<value>

    The language to use. Defaults to en-us.
    Options can be found in locale/ .

    Type: string

    Example: --locale=zh-cn

--doc_out_path=<value>

    The path to output generated documentation at.
    See --doc for more info.

    Type: string

    Example: --doc_out_path=C:/Users/Me/Documents/myLuaProjectDocumentation

[tomlau10]

Are there any plans on how this help page should be maintained / synced?
Directly parse the wiki github and generate the data table for this help page?
But content from the current LuaLS wiki maybe outdated? 😕

For example:

• the --num_threads (multi thread check: Add multi-process support to --check. #2638) is not listed
• the --force-accept-workspace is not working due to a bug mentioned here: Your workspace is set to 'x'. Lua language server refused to load this dir. #2975 (comment),
  it needs to be --force_accept_workspace before the bug is fixed
• the --check_format that you added recently is on this help page, but not on wiki page
  => so now this help page is "more updated" that wiki page

---

but then

• which one should user trust?
• how can they be synced?
• can the synchronization be automated?
  (not needed at the moment, but I think at least the overall direction should be planned ahead?)
• otherwise there will be 2 unsynced man page ...

might even be simpler

that --help just open/print the link to https://luals.github.io/wiki/usage/ and redirect users to there 😂 ?
here is a script generate by deepseek-v3, which looks promising 🤔

-- Import the platform module to access the platform.os property
local platform = require "bee.platform"

-- Define the URL to be opened
local WIKI_URL = "https://luals.github.io/wiki/usage/"

-- Open the URL based on the current platform
if platform.os == "windows" then
    -- On Windows, use the 'start' command to open the URL
    os.execute("start " .. WIKI_URL)
elseif platform.os == "macos" then
    -- On macOS, use the 'open' command to open the URL
    os.execute("open " .. WIKI_URL)
elseif platform.os == "linux" then
    -- On Linux, use the 'xdg-open' command to open the URL
    os.execute("xdg-open " .. WIKI_URL)
else
    -- For other platforms, print the URL as a reference
    print("Please refer to: " .. WIKI_URL)
end

[lewis6991]

The information maintained in this repo should be the source. This is where it is implemented.

Directly parse the wiki github and generate the data table for this help page?

No I don't think so.

that --help just open/print the link to https://luals.github.io/wiki/usage/ and redirect users to there 😂 ?

Honestly this sounds like a bad idea. I don't know a single tool that does this, and I would dislike any tool that does.

Having a usable --help shouldn't be controversial or need much discussion.

Maintenance of this information can be improved later, however I didn't do that here because I don't know if this will be accepted so I've kept the diff down.

In general, the cli code in this tool needs a lot of work. This is just a start.

[CppCXY]

please resolve conflicts, I have fix the workflow

[tomlau10]

The information maintained in this repo should be the source. This is where it is implemented.

That makes it clear 👍

Maintenance of this information can be improved later

You're right, that's totally fine at this stage.
With this decision is made, then maybe in the future wiki usage should instead be generated using the help page data table from this repo.

[AndreasMatthias]

Directly parse the wiki github and generate the data table for this help page?

I'd say the other way round is preferable. The repository (and each branch of it) should contain a recent help message. Including development branches. This means that the help message in the source code is updated frequently. While the wiki page should contain the help for stable releases only.

[AndreasMatthias]

@lewis6991
Lewis, I send you a PR with some updates of the help messages some time ago. Did you forget to merge it or are there any issues?

lewis6991@0b7c1b9

[lewis6991]

Sorry, I don't have notifications turned on for that fork.

[AndreasMatthias]

Sorry, I don't have notifications turned on for that fork.

No worries. I repeated the PR against LuaLS:master #3113