vim-rails and Ember .projections.json in subdirectory

[jgadbois]

I have a vim rails installed and an ember app in a subdirectory with a .projections.json. Any time there's a conflict (:Econtroller, :Eserializer) it's using the Rails projections instead of the Ember ones.

Is there a way to exclude this subdirectory from the Rails projections?

[tpope]

I'm afraid there's not, currently. My intended solution for this was to unify both plugins with the same projections system, but that's proving to be really difficult. If you're feeling ambitious, you can look into making RailsDetect() fail if keys(b:projectionist) contains a subdirectory of the Rails root, thus causing rails.vim not to activate at all in that case.

[juanibiapina]

@tpope If it's proving difficult, how about a config to disable it for now?

[tpope]

If you're feeling ambitious, you can look into making RailsDetect() fail if keys(b:projectionist) contains a subdirectory of the Rails root, thus causing rails.vim not to activate at all in that case.

[juanibiapina]

I'm not feeling ambitious. I was suggesting more in terms of early returning from RailsDetect based on a global config variable that I can set if I know I have projectionist or any other plugin which might conflict.

[tpope]

What? It needs to be conditional on the project. A global variable that unconditionally short circuited RailsDetect() would be the same as uninstalling rails.vim entirely.

[juanibiapina]

True. I would like to short circuit only the alternation, while keeping everything else.

[tpope]

If you're looking for a hack, duplicate your Projectionist alternates in config/projections.json or wherever. I'm not going to add a g:combine_rails_and_projectionist_in_the_way_that_is_easiest_for_juanibiapina option.

[juanibiapina]

That's not how I meant at all. I tried to say that if combining the two plugins is a long term goal and there is no easy way to integrate them now, there could be a correct, simple way to provide a config that disables only parts of the rails.vim behavior while keeping things consistent and solving a few of the common use cases.

I understand now that there probably isn't an good way, so it's better to keep the workarounds in our own vimfiles.

[tpope]

Which parts though? Your request for alternates seems tailor made your own particular config.

The next best thing to true unification is "innermost nested directory wins". This isn't some insurmountable challenge, it's just way down on my priority list.

[juanibiapina]

I just observed the conflict with the :As and :Es.

Another option is to drop the support for :As and :E completely from vim-rails and just integrate with a projectionist hook. But I admit I don't have enough knowledge of how vim-rails internally depends on many of the projection heuristics.

[tpope]

That's exactly the end goal. The problem is that rails.vim supports additional behavior, like the ability for :Econtroller with no argument to take you directly from the user model to the users controller, or the way :A takes you to from a migration to the next earlier one chronologically.

[juanibiapina]

Thanks for the explanations! I think I see the bigger picture now.