When the buffer's name is uniquified (because multiple buffers have
the same short name), it is no longer equal to the basename of the
buffer's file name, so it is incorrect to use the buffer name in the
rename operation.
Toggles are great and all, but the trouble with the various toggles for line
numbers is that they force you to remember and think about the fact that there
are variant forms of line numbers. To beginners or forgetful people the various
combinations of behavior can be unintuitive here (e.g. toggling off relative
line numbers does nothing if you are actual in visual line numbers mode). Though
it doesn't fit exactly into the normal stuff we have for toggles, due to the
complexity of this situation I think it is good to just have a way to say "line
numbers be gone!"
Wasn't sure what keybinding to use, so used a double-tap mnemonic.
If this PR gets rejected, there are a couple minor fixes that should probably be
pulled out and submitted separately.
When providing only the new directory path (i.e. without new filename) while
moving a file to a new directory with `spacemacs/rename-current-buffer-file`,
currently Spacemacs opens the file in a new buffer with the directory name.
Additionally, the `file-renamed-p` gets set the wrong value. To fix both
issues (with minimal work), it is easiest to just fix the `new-name`
value (alternatively fixing the `rename-buffer` and `set-visited-file-name`
forms later would not fix the wrong `file-renamed-p` value issue).
Finally when called with a universal-argument, then that argument
unintentionally gets 'passed' in the interactive call to
projectile-invalidate-cache. So this PR fixes that by changing the interactive
call to a funcall.
This reverts commit ec57b21a92.
A which-key change caused issues with this fix.
And the fix doesn't seem to be needed anymore.
The correct which-key entries appear without the fix.
problem
The evil-collection is loaded in the spacemacs-evil layer.
The spacemacs-evil layer isn't enabled by default
on the spacemacs-base distribution.
solution
Add buff-menu to the list: spacemacs-evil-collection-allowed-list
after the evil-collection has loaded.
This names the SPC F which-key entry.
before: +prefix
after: Frames
And adds "..." to the end of the descriptions,
for the keys that require additional user interactions.
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.
problem:
Reloading the configuration: SPC f e R
after changing the variable: dotspacemacs-fullscreen-at-startup
to: t
changes Emacs into fullscreen mode.
solution:
Only check the variable and change to fullscreen mode on startup,
before Spacemacs has been initialized.
Fixes: Reloading config with fullscreen-at-startup t (in macOS) toggles fullscreen mode #13073
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
"SPC d" was used for documentation related keybindings, such as in `dash`
layer.
But it's now used for `dap` layer exclusively.
Removing this won't cause any issue as `dap` layer would correctly set
the keybindings once it's loaded.
* Group `line-number` funcs under SPC t n
* Better name: absolute-line-numbers
Keep the old symbols around for backwards compatibility
Co-authored-by: Rostislav Svoboda <Rostislav.Svoboda@gmail.com>
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).
