Working on a PSR-2 composer project that's installed inside a Drupal root has proven painful. Whenever one opens another class file (which there's usually many in composer projects) makes flycheck (and I guess flymake) wine all over the buffer, and indentation is all wrong. Disabling drupal-mode and resetting all the relevant local variables is... A challenge.
When D8 lands, the issue is going to become bigger, as it's going to pull on more non-Drupal libs into vendor/.
@arnested what's your thoughts on the possibility of drupal-mode being able to restore everything it fiddled with when being disabled? My hunch is that it's a losing battle, even if drupal-mode made a note of everything and carefully restored the original values, there's always the possibility of some other lisp code reacting to things drupal-mode has touched...
So my gut feeling is that working on not enabling drupal-mode for non-Drupal files in the fist place is the way forward. The question is what the heuristics should be.
One easy thing would to add a hook-call or something around https://github.com/arnested/drupal-mode/blob/develop/drupal-mode.el#L848 that would allow one to tell drupal-mode if it should fire or not. Even, perhaps, ask the user if it seems a tossup. A default implementation that asks the user if the current file lies somewhere below a vendor dir might actually be a decent compromise for an alpha implementation.
Or, we could just assume that everything under vendor is not Drupal code, and leave it up to whatever the user has configured Emacs to per default. Might actually be the sensible way to deal with it.
Working on a PSR-2 composer project that's installed inside a Drupal root has proven painful. Whenever one opens another class file (which there's usually many in composer projects) makes flycheck (and I guess flymake) wine all over the buffer, and indentation is all wrong. Disabling drupal-mode and resetting all the relevant local variables is... A challenge.
When D8 lands, the issue is going to become bigger, as it's going to pull on more non-Drupal libs into vendor/.
@arnested what's your thoughts on the possibility of drupal-mode being able to restore everything it fiddled with when being disabled? My hunch is that it's a losing battle, even if drupal-mode made a note of everything and carefully restored the original values, there's always the possibility of some other lisp code reacting to things drupal-mode has touched...
So my gut feeling is that working on not enabling drupal-mode for non-Drupal files in the fist place is the way forward. The question is what the heuristics should be.
One easy thing would to add a hook-call or something around https://github.com/arnested/drupal-mode/blob/develop/drupal-mode.el#L848 that would allow one to tell drupal-mode if it should fire or not. Even, perhaps, ask the user if it seems a tossup. A default implementation that asks the user if the current file lies somewhere below a vendor dir might actually be a decent compromise for an alpha implementation.
Or, we could just assume that everything under vendor is not Drupal code, and leave it up to whatever the user has configured Emacs to per default. Might actually be the sensible way to deal with it.