Commit graph

11 commits

Author SHA1 Message Date
Eivind Fonn
2f4b05ddf5 Fix java layer after eclim package refactor 2016-08-30 16:03:19 +02:00
Eivind Fonn
5a869764dd Further improve gtags layer
- Add option to disable by default
- Use local-vars hook to allow per-project enable/disable
- Don’t enable helm-gtags-mode (no need)
- Move emacs bindings from helm-gtags-mode-map to ggtags-mode-map
2016-08-22 15:11:25 +02:00
Eivind Fonn
928983da47 Refactor jump to definition
This commit defines:

- spacemacs-default-jump-handlers: a list of functions that can jump to
  definition in ALL modes.

- spacemacs-jump-handlers-MODE: a list of functions that can jump to
  definition in MODE.

- spacemacs-jump-handlers: a buffer-local list of functions that can
  jump to definition. This is made up of the values of the two previous
  variables whenever a given major mode is activated.

- spacemacs/jump-to-definition: a function that tries each function in
  spacemacs-jump-handlers in order, and stops when one of them takes us
  somewhere new.

- spacemacs|define-jump-handlers: a macro that
  * defines spacemacs-jump-handlers-MODE, possibly filled with initial
    functions
  * defines a function that is added to the hook of the given MODE
  * binds “SPC m g g” of that MODE to spacemacs/jump-to-definition

This is an attempt to harmonize all the different approaches to jumping.
Specifically,

- Existing intelligent jump packages that work for only a single mode
  should go to the beginning of spacemacs-jump-handlers-MODE. E.g.
  anaconda for python, ensime for scala, etc.

- Packages like gtags that work for several modes (but potentially not
  all) and which is dumber than the intelligent jumpers should go the
  the END of spacemacs-jump-handlers-MODE.

- Packages like dumb-jump that work for all modes should go to
  spacemacs-default-jump-handlers.

In all cases the order of the jump handlers in each list should be from
most to least intelligent.

Fixes #6619
2016-08-22 15:08:25 +02:00
Diego Berrocal
219d891475 Update emacs-eclim package name
I think MELPA has an `old-names` back
[compatibility](https://github.com/melpa/melpa/issues/4159) measure for
cases like this, but for now it isn't working. And it's breaking all new
installs that use the java layer.
2016-08-18 21:12:15 +02:00
Ellis Kenyo
229ef0c05c Update the Java layer to support eclimd
Signed-off-by: Ellis Kenyo <elken@mykolab.com>
2016-08-05 21:15:58 +02:00
Christian E. Hopps
b22702bc9e Expand gtags use to many more languages 2016-07-17 17:31:59 +02:00
syl20bnr
173e2a5421 Move all prefix names from config.el to init functions 2016-04-03 00:12:28 -04:00
syl20bnr
33ead6fc42 Deprecation of extensions and <pkg>-excluded-packages variables
As announced in previous releases, see CHANGELOG.next for more info
in the Breaking Changes section.
2016-01-17 22:06:04 -05:00
syl20bnr
046d86800c Clean copyrights and update for year 2016 2016-01-11 21:42:17 -05:00
justbur
9befd20a1a layers: Transition to new key bindings functions
Removes dependence on evil-leader centralizing control over the method
of key binding in core-keybindings.el
2015-11-21 18:22:51 +01:00
justbur
6eab954afe Use + instead of ! for layer categories
Helm seems to treat "!" specially in pattern matching, so having a ! in
the pattern string when traversing directories is problematic. This
change fixes #2737, because as far as I can tell "+" has no special
meaning in a helm pattern.

Of course, we can choose a different character, but I'm fond of "+" as
representing "more layers here".
2015-09-11 00:13:51 -04:00
Renamed from layers/!lang/java/packages.el (Browse further)