Introduce hjkl-completion-navigation-functions to hold the functions to
disable and enable hjkl navigation for ivy and/or helm. The hook is run
with args to indicate whether to enable or disable.
Make use of new evil variable evil-disable-insert-state-bindings. This
is better because we are not copying evil code to get hybrid state to
work. We should not need to worry about tracking upstream evil changes
with this version of hybrid mode.
The only effect I can think of with this change is that there is no
longer a distinct hybrid-map, since there is no longer a distinct hybrid
state. This means that, for example, (evil-define-key 'hybrid ...)
will throw an error. You can either use (evil-define-key 'insert ...) or
the preferred (global-set-key ...). The latter is preferred because the
purpose of hybrid mode is to not interfere with Emacs bindings in insert
state.
Use post-init-evil function to load
It's a bit safer than with-eval-after-load, in case evil gets loaded
before its init function is called.
Add entry and exit hooks
Add temporary wrapper to evil-define-key
This is so that calls like (evil-define-key 'hybrid ...) do not fail
after switching over. Instead issue a warning for all such instances and
bind using define-key instead.
Also define evil-hybrid-state-map and make it the parent of
evil-insert-state-map this will prevent calls like (define-key
evil-hybrid-state-map ...) from failing.
These are both temporary and are only intended to smooth the transition
to the new version of hybrid-mode.
Unless there is a valid reason why these shouldn't be included I think
we should keep them. after all we can yank with `v y` right?
squash! Add documentation
evil-set-initial-state is safer than manually adding and deleting from
the lists, because it knows about all available states and ensures that
the mode only shows up in one list. If it is in multiple list the
initial state depends on which is checked first, which we don't want.
I've been introducing tons of people to Spacemacs, and most of them
always think that having to read documentation in how to add a layer is
too much.
I made this modification to make it easier to install layers.
This commit merge the `CONTRIBUTING.md` and `doc/CONTRIBUTE.org` file
into a new `CONTRIBUTING.org` file. It also refactors the content to be
more organized and make its navigation more goal-oriented.
Github displays a link to the `CONTRIBUTING.*` file when people are
opening new issues or proposing new PRs. This file is important because
it is the entry-point to contributions guidelines for most of the users.
The current setup is non-optimal, even broken, as it adds a level of
indirection, and points to a contributing file that has broken
links (due to the new documentation format). The possible drawback of
the proposed solution is that I'm not sure if it is possible to include
it into the new online documentation as it is not in `doc/` folder.
The other possibility is to keep a small `CONTRIBUTING.md` file, as it
is now, pointing to the new documentation system (once online), but I'm
preferring the proposed solution for the following reasons:
- People that are willing to contribute will probably open Github
first (for forking, creating PR, etc), not the online documentation.
- It has one level of indirection less when people click on the
guidelines guide from a new issue/PR.
- `CONTRIBUTING.*` is by convention a special kind of file on github, so
it's valid reason to break the rule and not having it in the `doc/`
folder.
Correct a bug in helm-spacemacs: Whenever a function was needing the
FAQ's candidates in helm-spacemancs (`SPC f e h` and `SPC f e f`), the
`FAQ.org` file was open in a buffer and not closed. This commit corrects
this by loading the content of `FAQ.org` in a temp buffer and switch it
to `org-mode` in order to get the candidates.
Add the `FAQ.org` file as a source in helm-spacemacs (`SPC f e h`).
Define a new keybinding for looking directly inside the FAQ with helm:
`SPC f e f`.
With help from TheBB, thanks!
