Currently using font-lock-preprocessor-face can make window number too
bright and distract. Use font-lock-comment-face to make it less
distracting while still visible since it's an inherent part of the
theme.
I found myself in <kbd>SPC : customize</kbd> without knowing how to switch out of it again when I was done, there was no menubar, and I couldn't turn it on either because the <kbd>SPC</kbd> keybindings or the Vim ones just didn't work at all.
Reading the documentation again I gave <kbd>fd</kbd> a try, and it brought the keybindings back, so I think it'd be helpful to mention that <kbd>fd</kbd> is also useful as an escape when the usual keybindings don't work.
Also wouldn't hurt if a message was displayed to use <kbd>fd</kbd> when trying to use <kbd>SPC</kbd> and it doesn't work.
Set popwin:special-display-config to nil and let us manage it from
scratch. Doing so, we avoid popwin to mess up windows of some package
i.e. SLIME. Similar to how auto-completion layer is managed, if a layer
want to have popwin support, it must be explicitly specified in that
layer.
The default popwin:special-display-config contains obsolete config such
as anything (predecessor of Helm) and buffer that should be stick around
until we press C-g (like shell command output since we may need the
output for doing something else).
We don't need to use popwin:display-buffer since it can still mess up
window configuration, like this issue #1409. Simply add helm buffers to
display-buffer-alist, and use display-buffer-in-side-window; without any
argument, the default is bottom. We also inhibit Helm buffers to reuse
the existing windows with (inhibit-same-window . t) and a window
height (window-height . 0.4).
Also prevent popwin from piling up display-buffer-alist since everytime
it is reactivated, it adds its own buffers that already existed in
display-buffer-alist, by restoring display-buffer-alist after
popwin-mode is enabled again.
- Replace `SPC h h` and `SPC h H` for `SPC h i` and `SPC h I`
- Replace `SPC r` prefix for `SPC x`
- Replace `SPC x SPC` for `SPC x r`
- Sort key bindings alphabetically
In a Helm window, the top header line displays a key binding to execute
persistent action. The key binding is C-j. The problem, not all sources
are applicable with C-j, i.e. helm-projectile-switch-project.
Removing the header line also makes Helm look cleaner.
The current whitespace faces make whitespace-mode too distracting to
read with too many background colors. This commit removes the annoying
colors for whitespace-space, whitespace-tab and whitespace-indentation
because:
- whitespace-tab and whitespace-space already use characters for
visualizing their appearances. whitespace-tab uses ">>" while
whitespace-space uses ".". Adding background colors is redundant and
annoying. Editors like Notepad++ or Vim doesn't use background colors
to depict such whitespace characters.
- According to the documentation of whitespace-indentation:
"Symbol face used to visualize 8 or more SPACEs at beginning of line.
Used when `whitespace-style' includes the value `indentation'."
It is used for highlighting first 8 characters or some customized
value. We must also disable its background colors otherwise our buffers
are still filled with annoying colors all over the places, since often
indentation is around 8 spaces or less. Anyway, with whitespace-space
and whitesspace-tab, such highlighting like whitespace-indentation is
redundant and not needed.
By using font-lock-comment-face, it's less distracting than the default
bright red, since comment face is designed to be subtle.
Also allow users to turn it off by adding an option
spacemacs-show-trailing-whitespace.
Originally `load-ess-on-demand` used `use-package` for the purposes of
actually loading `ess-site` and related elisp for dealing with R. But
since `use-package` doesn't return true or false when a package is
actually successfully loaded anymore, and the semantics of how it will
work aren't precisely clear, it makes sense to use `require` here
instead.
(defun load-ess-on-demand ()
(interactive)
(-all? '---truthy? (list
(require 'ess-site)
(require 'ess-R-object-popup)
(require 'ess-R-data-view))))
All the normal hooks setup by `use-package` will work as normal. I
actually don't see a reason we should use `use-package` instead of
`require` in this specific instance. Since `use-package` often defers
loading packages, it's arguably clearer to use `require` in this
particular instance.