The script used to identify and update the change is added into the GitHub
workflows script directory. A workflow action can be created to trigger the
script to update the headers on the first of every new year. Possibly a task for
a consequent PR.
in #15421 core cannot find a certain text in the home buffer
to start adding additional elements. This did fail the
start up process.
Now if the starting point is not found the cursor is set
to the end of the buffer instead and no error is signaled.
This allows to still have the home buffer work as expected
even when the starting point has been somehow removed.
- Fixed a bug that when `all-the-icons` is excluded by user, Emacs reports
that using undefined `all-the-icons` functions.
- Changed the `spacemacs-buffer-mode` that now it derives from `special-mode`.
- Also defined a new command `spacemacs-buffer/return` which binds to `RET`
key in `spacemacs-buffer-mode`. It opens the button on the current line if
there's any, or move the cursor to next line.
This commit locks the spacemacs home buffer in read-only mode.
Before this, users may use `SPC b w` to toggle it to writable but
this buffer really should not be modified by users.
Note that, when we need to modify the home buffer in LISP program,
we can always set `inihibit-read-only` to nil. Thus this commit
won't disallow us to update the home buffer when it's needed.
problem
Opening the full release note, leaves the cursor at the
beginning of the second line after the preview.
solution
Leave the cursor at the beginning of the first line after the preview.
problem
The number keys searches for a line starting with a number,
from the beginning to the end of the buffer,
even if they are above or below the window.
solution
Only search for the visible number lines.
problem
It might not be clear how the note can be closed.
solution
Add a button: Close note
to the bottom right of the notes:
Quick Help and Release Notes
This also defines the Spacemacs home buffer key bindings,
in the `emacs-startup-hook`.
Because the keys were being defined to early,
before the new value of: `dotspacemacs-show-startup-list-numbers`
was set in `.spacemacs`.
Added support for jumping to two digit numbers.
How quickly two numbers have to be typed,
can be modified with the variable:
spacemacs-buffer-multi-digit-delay
problem:
Pressing a number key on the Spacemacs home buffer,
doesn't reliably open the expected recent file.
cause:
The number keys are bound to open the files in the
order they are listed in the `recentf-list`.
The `recentf-list` is updated when a file is saved.
The home buffers recent files list is only updated
when the home buffer is created/refreshed/resized.
solution:
Open the recent files in the order they were listed
when the home buffer was last updated.
Fixes: incorrect order number in recent files on home buffer #14471
Define named functions: spacemacs-buffer/jump-to-...
for the home buffer shortcuts. So that a descriptive name is shown,
in for example the view-lossage (C-h l) buffer.
Before:
r ;; anonymous-command
p ;; anonymous-command
After:
r ;; spacemacs-buffer/jump-to-recent-files
p ;; spacemacs-buffer/jump-to-projects
`dotspacemacs-startup-lists` by default shows a number of recent files and
projects as two separate lists. If I've been working with a lot of files in one
project, then all the recent files are from one project, even if I set `recents`
to a large amount like 24. This change allows me to see the recent files by
project. Suppose, for example, I have a `vegetables` project and a `fruit`
project, and set `dotspacemacs-startup-lists` to `(recents-by-file . (2 . 3))`.
In the home buffer I will see something like:
~/vegetables
lettuce.el
squash.el
tomatoes.el
~/fruit
apple.py
orange.py
banana.py
Even though only a subpath is displayed for each file, the click functionality
still works---i.e. the link still has the full path under the covers.
I originally asked a [question](https://emacs.stackexchange.com/q/62524/19069)
on Emacs StackExchange to see if there were any pointers or if this was already
a solved problem. After several days of receiving no answers, and having a
little time to poke at it, I figured I'd implement it myself.
What this does not cover: mixing recent files totally outside projects into this
list. Today they are just filtered out. That is a usecase I didn't need so I
figured that could be done in a subsequent pass if somebody wanted it.
The new variable was not following the naming conventions.
The file was not initialised in core-dotspacemacs.el.
The file was not part of the .spacemacs.template.
- Removed the first line deletion.
This required the banners to have an empty first line.
- Removed the empty first line from the banners.
- Made sure that there is a single empty line between:
- The Version and Banner.
- Banner and Buttons ([?] [Homepage] ...).
- Version and Buttons (when the banner is hidden).
- Reordered the backend version insertion function call
to match the frontend Spacemacs buffer order.
- version
- banner
- buttons
Before it added:
- the banner
- then the buffers first line was removed
- then the version was added to the first line
- then the buttons were added at the bottom of the buffer
(there are more things added after the buttons,
but they haven't been changed by this commit).
- Removed the version insertion call in:
core/core-spacemacs-buffer.el
The changes above caused the version to appear twice
in the Spacemacs home buffer on startup.
I'm not sure if it has/had other uses.
This seems to be where it was first added to:
core-configuration-layer.el:
core: restore default mode line in home buffer
77161bd591
It was slightly modified in this commit:
core: defer distro insertion in home buffer
cd50d9c069
Here it was joined with the banner:
Fix version injection in home buffer
Don't inject version if banner is nil
a764eb4eb9
core: condensed versions into one string in left-hand side
spacemacs-version@emacs-version (distribution)
627e934453
- I had not seen that the version was joined with the
banner on purpose until now.
It seemed useful to still be able to see the versions
if one just wanted to hide the banner.
Therefore I opened this PR (it's been cherry-picked):
Uncouple version from banner in spacemacs buffer #11901https://github.com/syl20bnr/spacemacs/pull/11901
If there's a good reason to combine them again,
then the changes can be reverted.
The line in the Spacemacs home buffer that shows the Spacemacs version, Emacs
version and the Spacemacs distribution, for example: "0.300.0@26.1 (spacemacs)"
were tied to the banner. The line disappeared when the banner was hidden.