Emacs 26.1 will introduce a new native line numbers feature:
"display-line-numbers". It includes relative line numbers, is faster than
current linum-mode, and doesn't use the margin area (it has its own area). So
yeah, we want to use the new feature when possible.
No changes are required on the user side, except for Emacs 26 users are
recommended to remove nlinum layer from their configuration (if they have
enabled it).
With this change:
- Emacs 26:
- uses display-line-numbers by default.
- linum and linum-relative packages are excluded.
- Emacs 25:
- does NOT use display-line-numbers.
- continues to use linum and linum-relative.
- nlinum layer:
- can still be used as before in Emacs 25.
- is NOT recommended in Emacs 26, but can be used.
- when enabled, excludes display-line-numbers.
Also contains some bug fixes:
Fixes a bug where setting `dostpacemacs-line-numbers` to `t` or `relative`
enabled line numbers in every buffer, instead of only in buffers that derive
from prog-mode and text-mode.
Likewise fixes a bug where specifying `:enabled-for-modes nil` (or not
specifying `:enabled-for-modes` at all) in `dotspacemacs-line-numbers` settings
meant "enable in all modes" instead of "enable in modes derived from prog-mode
or text-mode".
Because of this change, also adds a way for users to enable line numbers
in *all* buffers.
Removes check for special buffer. All our current checks should be enough to
enable line numbers only where it makes sense. Disabling in all special buffers
is not necessary.
This idea is to have the spacemacs-base distribution only configure defaults for
built-in packages. Those buit-in packages are now configured in the new layer
spacemacs-defaults.
Additionally some other packages of spacemacs-base have been dispatched to
better suiting spacemacs layers.
Projectile has been moved to the new layer spacemacs-project
- Move the following packages to bootsrap distributio layer:
- exec-path-from-shell
- evil-evilified-state
- holy-mode
- hybrid-mode
- spacemacs-theme
- ace-window has been moved to spacemacs-navigation
- centered-buffer-mode has been moved to spacemacs-editing-visual
- pcre2el has been moved to spacemacs-editing
- evil-escape and evil-visualstar have been moved to spacemacs-evil
This reverts commit 29c78ce841 and all other fixes
that have been made afterwards.
The motivation is that use-package is seen by many as a replacement for
`require`. Is use-package always defer the loading of packages then is breaks
this use case, this does not respect POLA so even if it was making Spacemacs
loading faster (up to 3s faster on some startup on my machine) we just cannot
use it, it would be irresponsible. Spacemacs should be easy to use, loading
performance will come with time but it is not a priority.
Delete layer evil-cleverparens and move the package to spacemacs-evil layer.
The feature is called "Safe structurral editing" for lisp dialects. Support for
it is added via pre-init functions in each of the concerned layer and proper
documentation is added to their README.org files.
This also removes the recently added package evil-smartparens. The goal is
to choose the best package for evil safe structural editing. For now we use
evil-cleverparens as we supported it first, if evil-smartparens is shown to be
a better package we will be able to switch to it.
Problem:
Spacemacs rewrites the evil-mc-mode-line variable, to remove the evil-mc mode
line text, when there's only one cursor. The rewrite blocks the recent evil-mc
updates, that made the multi cursor, mode line text, more readable.
Solution:
Use the new evil-mc-one-cursor-show-mode-line-text variable, to only hide the
mode line text, when there's one cursor. This unblocks the current, and any
future updates, that the evil-mc package makes to the mode line text.
The unimpaired keybindings `[ q` and `] q` can be used to jump to flycheck
errors in the current buffer. Because evil-repeat treated them as regular
operations, they were repeated when pressing the `.` key. This made it harder to
rename multiple erroneous variables.
There was an error in `linum-on` when `dotspacemacs-line-numbers` was set to
`'relative`.
- new function `spacemacs//linum-backward-compabitility` to test for old
supported values.
- Use an :around advice for `linum-on` instead of redefining it.
- move linum init time config to `:init` section of `use-package`
- fix relative linum initialization by testing if `dotspacemacs-line-numbers` is
a list first.
Choose to inherit from face lazy-highlight instead of region.
Ideally a theme should not set lazy-highlight to the same face as
region.
Also move some function to funcs.el and remove some empty lines.
To use nlinum + nlinum-relative add the nlinum layer
Note: there are still work to do on nlinum-relative, at some point we
may replace linum by nlinum completely.
Motivation
While disabling Evil in holy-mode makes its implementation shorter and
sounds elegant on the paper, in practice it puts a big burden on the
configuration parts which need to know if Evil is enable or not. This is
a bad separation of concerns and the bunch of fixes that we were forced
to do in the past weeks shows this issue. Those fixes were about
removing the knowledge of the activation of Evil by implementing new
dispatching functions to be used by layers, this is cumbersome and makes
Spacemacs layer configuration more subtle which is not good. There was
additional bad consequences of the removal of Evil state like the
impossibility to use Evil lisp state or iedit states, or we would have
been forced to implement a temporary activation of Evil which is
awkward.
Instead I reintroduce Evil as the central piece of Spacemacs design thus
Evil is now re-enabled in holy-mode. It provides the abstraction we need
to isolate editing styles and be able to grow the Spacemacs
configuration coverage sanely. Layers don't need to check whether the
holy mode is active or not and they don't need to know if Evil is
available (it is always available). We also don't need to write
additional dispatching functions, this is the job of Evil, and I think
it provides everything for this. Ideally configuration layer should be
implemented with only Evil in mind and the holy-mode (and hybrid-mode)
should magically make it work for Emacs style users, for instance we can
freely use `evil-insert-state` anywhere in the code without any guard.
Evil is now even more part of Spacemacs, we can really say that
Spacemacs is Emacs+Evil which is now an indivisible pair. Spacemacs
needed this stable API to continue on the right track.
While these changes should be rather transparent to the user, I'm sorry
for this experimental period, I failed to see all the implications of
such a change, I was just excited about the possibility to make Evil
optional. The reality is that Spacemacs has to embrace it and keep its
strong position on being Emacs+Evil at the core.
Implementation
- insert, motion and normal states are forced to emacs state using an
advice on `evil-insert-state`, `evil-motion-state` and
`evil-normal-state` respectively. These functions can be used freely in
the layer configuration.
- A new general hook `spacemacs-editing-style-hook` allow to hook any
code that need to be configured based on the editing style. Functions
hooked to this hook takes the current style as parameter, this
basically generalize the hook used to setup hjkl navigation bindings.
- ESC has been removed from the emacs state map.
- Revert unneeded changes
- Revert "evil: enter insert-state only from normal-state"
commit bdd702dfbe.
- Revert "avoid being evil in deft with emacs editing style"
commit f3a16f49ed.
Additional changes
All editing style packages have been moved to a layer called
`spacemacs-editing-styles`
Notes
I did not have time to attack hybrid mode, I should be able to do it
later.
