Auto completion for struct fields Elixir ls

I’m using the forked plugin and do have auto-completion for struct fields.

struct-autocomplete846×375 33.5 KB

Makes sense, I was expecting the wrong thing, taken the image you posted for example, I was expecting that there would be autocomplete available for the scenario where I type in a.value, which is what I saw being used in the videos using elixir with emacs . I guess I misunderstood.

Thanks for the reply.

I don’t think you were expecting the wrong thing. I just answered the wrong question haha. What you were expecting would be way more valuable to me too and I assume most others. I’ll look into it a bit more but it should be possible.

A little side question… How are you finding Elixir so far? I see you come from statically typed functional languages and I would love to hear your experience. Elixir is by far my favourite language because of it’s simplicity, readability and power but I hate that it’s dynamically typed. Even after years of playing with it I sometimes struggle working out what “type” arguments a function is supposed to take.

Re: arguments - it’s quote easy to add types to function arguments (guards and inline stuff like fnname(foo = %Abc{}). For me that’s good enough level of static typing

As mainlymortal mentioned auto-completion for struct fields is supported within struct definitions for ElixirLS. In practice (for me at least) this isn’t too large of an issue because I generally prefer pattern matching out fields of a struct because then the code will fail to compile if I change a field name. If you use the my_struct_instance.my_field version then you will get a runtime error if you rename your field from my_field to my_better_field. So instead I typically do %MyStruct{my_field: my_field} and then use my_field in the rest of the code.

I suspect that Dave may have either been using Alchemist.el (unfortunately no longer maintained), although I’m not sure if it has the feature that you want, it may have been using some type of heuristics to guess the variable type (or that could have been supplied by some other emacs plugin).

I think elixir would be the best functional language available if it had a HM type system.

Currently, I have programmed professionally in Scala only, and I don’t miss it at all. The complexity of managing to exist in that ecosystem was unbearable, you just never know what to expect. One minute you’re coding like it’s Haskell, and then the next you’re dealing with some huge inheritance hierarchy, and implicits OMG, don’t get me started. I still have nightmares about SBT. I will never accept a job using Scala again.

Other than that, I have written programs using Kotlin, and F#. One thing Elixir, Scala, Kotlin, F#, Clojure all have in common is that they are all built on top of pre-existing platforms, and this is where ( so far ) Elixir outshines all of the competition to me. In Kotlin, Scala, and F#, as soon as you pull in a dependency from the Platform ( jvm / .net), you are right back in OOP land, which defeats the whole purpose. Sure you get access to a huge ecosystem, but at what cost? To some, it may be worth it, but to me, it’s not.

My job requires me to program in Go, which is not as bad a language as a lot of people make it out to be, but if you think functionally, it sucks. For me, Elixir is like the Golang of the Functional programming world, to some that may sound like an insult, but it’s not. Elixir is super simple, and simplicity is hard. Go is unapologetically procedural and it makes very few compromises. It’s a very stripped-down language that gets out of your way and lets you do everything you need to do in order to get work done ( albeit very procedural manner ) and has very good support for concurrency. I would choose it over any OOP language available in a heartbeat.

Elixir is the same except for it lets you do everything you need to do in a functional manner, and it ( like Go ) has great support for concurrency and makes no compromises about what it is. It is not a confused language and it did not have to add language constructs that do not fit its paradigm in order to adapt to the underlying platform, I like that a lot.

I have realized that this is the preferred way of doing things in Elixir, and it’s actually quite nice. I think it’s going to take me some time to get used to the idiomatic way of doing things in elixir.

Thanks for the reply, I think that what is provided by the plugin will be fine for now, I just need to adjust my code to what you advised, pattern matching seems like much more idiomatic elixir approach than accessing struct fields by name.

I do think it would still be a nice added feature though.

Yeah, I agree that it would be a nice feature. An PR’s that implement that would most definitely be welcomed

I’m afraid I need to get my Elixir skills up to par a bit first, but once I feel ready for it, I’d definitely be open to contributing.