The settings were initialize in an autoload which is not a good
practice.
So I initialize them in the plugin directly, this way there are
initialize only once when the plugin is loaded and they can be access
anywhere without having to worry about what the default value.
It is still not possible to override an existing hook but with this
system users can create new hooks really simply without having to update
any configuration since they will be autodetected.
The only missing thins is the possibility to disable hook, therefore it
is the responsibility of each hook to provide a way to the user to use
it or not.
This solve the issue #19
I put it there as an example, it might be better in its own repository.
This way a user will be able to choose to use it or not, which will
allow them to be able to provide their own implementation.
This attempt only deal with methods.
Functions are not part of the PSR-2.
Closures should always have the opening brace on the same line as the
closing parenthesis, this extension is not a CS fixer and therefore as
no reason to deal with them.
A first step to make the plugin extendable.
This allow to add logic on a per filetype basis.
This solution allow a user to extend the behavior if the plugin does not
provide a hook for the given filetype.
But if there is already a hook then the user can not create it's own.
One solution could be to find every functions defined in the namespace
`argwrap#hooks#user#<ANYTHING>#post_wrap`, I think airline provide a
feature like this.
Those hooks would need to be sorted in order to have a predictible
behavior, also it might be interesting to provide a way for each hook to
update the range, container and arguments.
There might be nothing to do because I think Vim's lists and dictionaries
are passed by reference.
For example in VimL with the following declaration:
autocmd FileType vim let b:argwrap_line_prefix = '\ '
The following line will be properly wrapped:
let t = {'one': 'whatever', 'two': 'whatever'}
Into:
let t = {
\ 'one': 'whatever',
\ 'two': 'whatever',
\ }
But when trying to unwrap it will do:
let t = {'one': 'whatever', 'two': 'whatever', \}
This is caused by the "trim" done for each "extracted" piece of text,
which result in having '\' instead of '\ ' for the last line.
