CppCXY / EmmyLuaCodeStyle

fast, powerful, and feature-rich Lua formatting and checking tool.
MIT License
140 stars 27 forks source link

Name-style check configurations #105

Closed AndreaWalchshoferSCCH closed 1 year ago

AndreaWalchshoferSCCH commented 1 year ago

As I now want to use the name-style checks of this library (since they give more/better options already), a few questions have came up.

I try to use it through sumneko LuaLS (both VSCode and CLI), but I have now also tried the EmmyLuaCodeStyle VSCode Extension. Configuration of e.g. whitespaces, so code-style, works fine and the same for both versions.

What I tried to configure in .editorconfig:

enable_name_style_check = true

local_name_define_style = camel_case
function_name_define_style = camel_case
local_function_name_define_style = camel_case
global_variable_name_define_style = upper_snake_case

I have noticed that the docs for the name-style checks are only in the "old" documentation. But I tried it like it's described there.

CppCXY commented 1 year ago

as you can see, I didn't give you how to configure namestyle, I refactored all the code after the 1.0.0 update, but I forgot to write the code for namestyle to read from the configuration. on the other hand, I felt that name-stylecheck should not be configured with editorconfig, and I planned to reprogram a configuration file, but I didn't think of a good name, so I never did it

AndreaWalchshoferSCCH commented 1 year ago

Would it be an option to provide you a PR that reads the configuration from editorconfig for now, as it could always be refactored into a separate configuration file at a later point?

Also - would that already solve the problem of the LuaLS not giving any namestyle warnings, or is that something that would need attention in LuaLS as well?

CppCXY commented 1 year ago

I separated code-style and name-style, Luals only has the code-style part. to enable name-style, you need to add a diagnostic code to Luals. It can be a little difficult to write this pr for you. It's better to read it from json

AndreaWalchshoferSCCH commented 1 year ago

Okay so as far as I understand the LuaStyle (=code-style) has to parse the .editorconfig itself, while using json should make that a little bit more... compact. And LuaDiagnosticStyle =name-style) is mainly missing this configuration parsing. A json library is also already in the repository.

If that's correct so far, I could write a small prototype using .luarc.json which should be found at project root as well. And we could discuss from there.

As for the LuaLS diagnostic code (which as a first step doesn't necessarily need the configuration) - I would start by taking the https://github.com/LuaLS/lua-language-server/blob/master/script/core/diagnostics/codestyle-check.lua and adapt from there. Or does activating name-style need a different approach then code-style?

CppCXY commented 1 year ago

luaStyle is simply created from map, not editorconfig file, editorconfig file is read by luaEditorconfig. so luaDiagnosticStyle is also created by maps or other structures, not .luarc . the entire CodeService does not rely on the JSON library, which is used for CodeFormatServer. LuaLs is calling CodeFormatLib for service, if you want to get the configuration from .luarc, you should pass in the Map via CodeFormatLib and parse out LuaDiagnosticStyle

CppCXY commented 1 year ago

You don't need to do the work anymore, I'm implementing related work, naming style checking will support regular expressions and basic nomenclature. image

AndreaWalchshoferSCCH commented 1 year ago

Oh thank you very much for the work, and thanks for letting me know! I've figured out the LuaLS diagnostic in the meantime - did or do you implement that as well, or should I just contribute that?

AndreaWalchshoferSCCH commented 1 year ago

Loosely related issue I've just come across: The start and finish of diagnosticInfos given by the name_style_analysis do not include the last character of the offending name if it is longer than one character (and it looks like it looking correct with one character names is some special handling as well)

For example:

local NAME = "test"

the namestyle returns start = 6 and end = 9 (resulting in only NAM being marked) , but other diagnostics in LuaLS would give start = 6 and end = 10 to correctly mark the name. Also, the EmmyLuaCodeStyle VSCode extension does correctly mark the whole name.

The problem in LuaLS can be fixed by just increasing the end-index by 1 in the diagnostic for all cases (one-character names are still marked correctly, as well as all longer names). But before doing that, I'd like to clarify if that discrepancy is intended and should in fact be fixed in the LuaLS diagnostic, or if it is rather a bug and is better changed in the CodeFormatLib?

CppCXY commented 1 year ago

It is design, my design is [start, end] not [start, end), and my language server can converts. you can add 1 to end-index

CppCXY commented 1 year ago

I fix the question by myself. I am working for luaLs adaptor. you can do some translation work for me

AndreaWalchshoferSCCH commented 1 year ago

Yes sure, just let me know where exactly you can use my help.

CppCXY commented 1 year ago

I have complete all, see https://github.com/LuaLS/lua-language-server/pull/2091

CppCXY commented 1 year ago

It may be difficult to integrate this part into LuaLs, my own plugin has been released, you can try it

AndreaWalchshoferSCCH commented 1 year ago

Nice work! I've now tried the EmmyLuaCodeStyle VSCode Extension directly, as well as the implementation of your LuaLS PR in my dev environment. I really like the way it works. It also works as expected in both plugins if the configuration is done in settings.json, the only thing I'm missing is that for the LuaLS it doesn't apply the configuration when I put it into luarc.json instead (where I actually enable the name-style-check diagnostic in my setup). When using the LuaLs directly, it also works as expected with the luarc.json