problem:
the attempt to hide the dired buffer, which-key entry:
r -> evil-mc
caused a void dired-mode-map message to appear on startup,
in the spacemacs-base distribution.
solution:
hide the which-key entry after dired loads.
problem:
pressing g shows the which-key entry:
r -> evil-mc
but it calls the expected commands:
revert-buffer (in dired)
magit-refresh
s -> evil-easymotion
but it calls the expected command:
magit-jump-to-staged
solution:
removing the gr and gs which-key entries,
shows the expected commands.
Moved the function definitions for:
spacemacs//trailing-whitespace
spacemacs//set-whitespace-style-for-diff
from: spacemacs-default/packages.el
to: spacemacs-default/funcs.el
problem:
key bindings that use the winum package,
don't work in the spacemacs-base distribution.
for example in the buffer transient state: SPC b .
{number}, C-{number} or M-{number}
shows messages like these:
Wrong type argument: commandp, winum-select-window-1
Symbol’s function definition is void: winum-get-window-by-number
cause:
the winum package is loaded in the spacemacs-navigation layer,
but the layer isn't used in the spacemacs-base distribution.
solution:
show the message:
This command requires the winum package,
winum is part of the spacemacs-navigation layer.
This avoids more problems found by @duianto.
Also:
* Use more descriptive variable names
* Print message explaining lack of narrowing in visual block mode
* Apply @duianto's fix to only activate visual selection it if it was active
previous to the creation of the indirect buffer
* Block use of visual block mode because of continuing problems in that mode,
and its questionable usefulness in this case
* Extract commonalities out of the narrowing functions
* Make the new keybindings into a list in the changelog for readability, per
@duianto
problem:
The following error messages are shown.
When trying to move, select or swap the current buffer,
to a window nr greater than the total number of open windows.
For example:
With only one window open.
`SPC b 2`
>ad-Advice-select-window: Wrong type argument: window-live-p, nil
In the Buffer Transient State (`SPC b .`):
- `C-2` (`spacemacs/buffer-transient-state/winum-select-window-2`)
>Wrong type argument: window-valid-p, #<window 12>
- `2` (`spacemacs/buffer-transient-state/move-buffer-window-no-follow-2`)
>Wrong type argument: window-live-p, #<window 14>
- `M-2` (`spacemacs/buffer-transient-state/swap-buffer-window-no-follow-2`)
>Wrong type argument: stringp, nil
Solution:
Show a descriptive message, if the target window nr is greater than the number
of open windows. And ignore the LV buffer (hydra).
Removed the parentheses around the buffer name number,
because the angle brackets are enough.
Added the frame argument.
Rewrote the accepted SPLIT arguments as a table.
problem:
the variable names: `dir`, `name`, and `filename` leads to confusion if they are
the old or new names
solution:
add the prefix `old-` to match `new-`,
use (`old-` `new-`) + `short-name` for just the `file.ext` (the `short-` idea
came from the `spacemacs/rename-file` function that's defined above this one),
and `old-full-path` instead of `old-filename` makes it clear that it's not just
the files name and extension.
problem:
renaming a file to it's current name, results in the message:
"File 'current-name' successfully renamed to 'current-name'"
solution:
when the new and old names are the same, show a rename failed message, and call
the rename function again
problem:
the rename command shows the same message:
"File 'old-file-name' successfully renamed to 'new-file-name'"
(without the directory path) for all three file operations:
move, rename and both move & rename
solution:
show messages that fit the rename operation,
and align the from and to path/file names,
to make it easier to see what changed.
And use the same message format when renaming a buffer.
Follow up the changes in the previous commit with some minor improvements
to formatting, grammar, spelling, and wording.
* layers/+distributions/spacemacs-docker/README.org: Replace "+" with
"and".
* layers/+email/mu4e/README.org: Use full sentences in the comments in the
mu4e-alert example.
* layers/+intl/japanese/README.org: Use verbatim markers for names of
files, functions, packages, and variables. Capitalize "Linux".
* layers/+os/osx/README.org: Capitalize "Emacs", "Vim", and "Evil".
* layers/+os/osx/config.el (osx-command-as, osx-use-dictionary-app):
* layers/+os/osx/keybindings.el (spacemacs/system-is-mac): Improve
docstrings.
* layers/+readers/dash/README.org: Capitalize "API", "Helm", and "Ivy".
* layers/+spacemacs/spacemacs-defaults/config.el
(delete-by-moving-to-trash): Use full sentences in comment.
* layers/+spacemacs/spacemacs-defaults/funcs.el
(spacemacs/toggle-frame-fullscreen-non-native): Improve docstrings.
Update 'spacemacs|create-align-repeat-x macro to add a docstring to created
functions. The docstring refers the user to the macro, providing a link to
the source code.
Emacs 26 added built-in support for line numbers, relative line numbers, and
visual line numbers. Spacemacs supports only absolute and relative, but there is
no way to access the visual mode. It's hard to get around this, since Spacemacs
abstracts line numbers to a reasonably high degree.
Arguably, `visual` is much more useful than `relative` as a display type. Visual
line numbers are like relative line numbers, but only lines that are actually
showing are counted. This means:
1. Hidden lines are not counted. If a large amount of text is folded, the line
numbers won't jump from "10" to "546". This is particularly useful in
buffers like `magit-status`, where a large amount of information is folded
by default.
2. Lines that are wrapped are counted as multiple lines, since they're being
displayed as multiple lines in the editor. Each visual line will be
numbered - unlike `relative`, where the entire thing is numbered... Once.
With standard relative line numbers, you can't actually navigate using the line
numbers in the sidebar as soon as folded or wrapped lines are introduced. Since
this is one of the main use cases for relative line numbers, this is a big
problem.
Visual mode fixes that problem. Every line that's being displayed is labelled.
Numbers always correspond to the actual number of lines you'd need to navigate
to reach that line.
This commit extends Spacemacs' line number interface to provide visual line
number support.
