Closed hcs42 closed 10 years ago
I like this idea. I think the best way to handle the options is to pass the parameters directly. E.g.
let g:erlang_check_flymake_params = '-xref -reldir rel/'
The flymake call would be execute "silent lmake %" g:erlang_check_flymake_params
. This means that a user can use the vim compiler manually: make % -xref
(useful for selective loading). You can probably come up with better variable/parameter names.
I don't like the idea of messing with existing release. xref warnings would be super cool to have.
I don't like the idea of messing with existing release.
It was standard development practice at my previous Erlang project, and it is quite convenient. But you are right that it should not be turned on by default. Do you have concerns even if the users have to activate it manually (like editing g:erlang_check_flymake_params
as @fishcakez described above)?
No, not at all. Disabled by default makes it a sane default IMO.
Load the beam file into a running node.
:clap: Please please please show me
Also, re: configuration: global variables passed via command line sounds good; default off also good preferable :+1:
Thank you for the answers. I'm closing this ticket because it was about discussing the question of configuration, and that has been discussed :)
Here is my PR with the changes mentioned above: https://github.com/vim-erlang/vim-erlang-compiler/pull/6
I have added the following features to my copy (it needs to be cleaned up before I push it):
rel
with the same name and overwrite them. This way if the node is restarted, it will still use the new version of the module.My question is: how is it best to configure these features? All of them should be optional, and the user must be able to set e.g. which Erlang node to load the code into, which directory to use as
rel
.My idea is to have these config items as global Vim variables that we can pass to
erlang_check.erl
as comment line parameters.