CLI design

[jayvdb]

#3 is a very hacky first cut at making the CLI usable and understandable with README steps.

There are not many LSP clients with a usable CLI.

https://github.com/Artawower/smells-code-analyzer uses a JSON config file to specify all the info needed, with only a single arg --threshold <value> for "Max amount of dead code entities".

https://github.com/valentjn/lsp-cli looks to be more mature, and also uses JSON config file, but includes many more CLI args, some of which override the config file. The README description of its config file is quite confusing, but it looks like it can define multiple LSP servers.

I am thinking that using a config file is desirable, and should be more like smells-code-analyzer , defining a single LSP server, and how the client should utilise the LSP. If someone wants to talk to multiple LSP, create multiple config files. There is some efficiency in a CLI talking to multiple LSPs - then errors from multiple LSPs can be shown all together, however IMO that isnt worth the complexity. If we get that advanced, this could be supported using something like --config ts.json,lua.json,python.json with three separate configs

[theskcd]

Yeah, I think that works. I think with clap you can also accept Vec as input from the cli command so hopefully we do not have to parse using , but maybe my memory is being wrong here.
The first PR in this flow looks really good. I will let you keep hacking :)