Open OvermindDL1 opened 8 years ago
As per halohalospecial, atom-text-editor:not([mini])[data-grammar^="source elixir"]
or something like it should fix it.
I do not see this on Fedora24 Atom1.10.0 atom-elixir0.2.1
@rubencaro Using what packages? For example it breaks elmjutsu plugin by hooking the autocomplete-confirm command everywhere, including elm files, instead of just elixir files.
@OvermindDL1 I use builtin autocomplete with at least Python, Markdown, Yaml, Erlang, Ruby and Javascript. All while using atom-elixir with Elixir.
The only issue I see is this #36.
Maybe you mean atom-elixir is breaking autocomplete plugins other than the builtin one. That I cannot tell.
Maybe you mean atom-elixir is breaking autocomplete plugins other than the builtin one. That I cannot tell.
That indeed might be it. What is happening is elmjutsu is relying on the keycodes passed from autocomplete-plus, but when atom-elixir is hooking that with its own handler and not passing the autocomplete-plus fully compatible structure then it breaks.
What is odd, it should not be hooking it at all unless in an elixir file, it should not be touching autocomplete-plus for elm files at all.
Currently atom-elixir is hooking the autocomplete-plus:confirm with its own command, in all contexts, not just in source.elixir type files: https://github.com/msaraiva/atom-elixir/blob/master/lib/elixir-autocomplete-provider.coffee#L16-L34
This is breaking autocomplete in other autocomplete plugins for other languages since the re-cast event is missing data, such as for elm: https://github.com/halohalospecial/atom-elmjutsu/issues/5
A fix would be to either copy the old event and re-type it to "autocomplete-plus:confirm" and send that one, or a better fix would be to only register in elixir files, and best would be to do both.