Added the '-module' attribute snippet

[gravemalte]

Description

I added the -module(Module) attribute into the available snippet list. As for the placeholder I took Module because of the Erlang docs.

Feedback is welcome, thanks!

[robertoaloi]

Hi @Daylien and thanks for your contribution. The module name is supposed to coincide with the filename, so I wonder if we could default to that, instead. That's the behaviour that I already get in Emacs, for example. In other words, if I have open roberto.erl, the module name would default to roberto. We just need to be careful adding single quotes whenever the filename requires it (e.g. it contains a dash).

[gravemalte]

Hey @robertoaloi thanks for the answer! Yeah I though the same, I came up with the idea, to reuse some concepts from the behavior of https://github.com/erlang-ls/erlang_ls/blob/cd050eb506b784b94adfffa3edd20bc4962f678d/apps/els_lsp/src/els_completion_provider.erl#L275-L292

It's more or less the same for the -module(Module) attribute, but only the relative path in which the file is created is relevant for the completion. What's your opinion on that?

I will dig myself more deeply into the code base. So stay tuned!

[gravemalte]

I added the basic auto-completion functionality. Feedback is really welcome.

Thanks!

[gravemalte]

Sorry about the delay in the review, I left some comments. I hope they make sense :)

Thanks for the good feedback!

I will work your mentioned changes in after the holidays. Beside that, I wish you a merry Christmas and a happy new year. Stay tuned for my changes in early 2022.

[gravemalte]

Hey @robertoaloi!

I continued working on this and I created a little regex match to match against "invalid" chars. All is working fine beside the special characters problem @!$ and so on (but - is working). So far so good.

But here is the big deal. The problem also affects the -include(...) and include_lib(...) completion trigger. To test it, create a file which is called [email protected]. On triggering the autocompletion provider you will notice that the @ will be resolved into Latin1 hex so the name is now my%40header.hrl and this is cracking my work also up. I will push my code when I know why the path is in hex Latin-1 and not in the "normal" Latin-1 format.

Also I discovered the following at https://www.erlang.org/doc/apps/stdlib/unicode_usage.html.

In Erlang/OTP 20.0, atoms and function can contain Unicode characters. Module names, application names, and node names are still restricted to the ISO Latin-1 range.

Latin-1 is fine for module names but here we talk about filenames which should be treated as UTF-8 AFAIK (please correct me if I'm wrong).

My guess is that the problem lives in els_utils.erl or more precise in the path(Uri) function.

Maybe you have an idea why this behavior is what is it currently.

[plux]

Implemented in #1486