this is caused by the home buffer loading build-in
org which conflicts with elpa org.
We actually want to use elpa org exclusively so we have
to make sure to redraw the spacemacs buffer only
after we have finished loading the layers.
In addition latest org version 9.6 and the behaviour
on emacs 29 has also changed so that org is autoloaded
much earlier than before. This is what actually did
make this bug show up.
However this behaviour was in place since a long time
and could be the cause for a lot of unreproducible
bugs as the actual conflicts are dependent on the
distribution specific emacs version.
Known issues:
This is a hotfix it solves the original issue but
introduces a new, hopefully less dangerous issue,
this is for now the start buffer is not configurable.
I will add a follow up PR to remove this issue however
I think this is far less annoying than a set of random
conflicts caused by loading elisp files from different org
sources.
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.
with this curent (package :location local) can be replaced with (package
:location (recipe :fetcher local)) then quelpa will install local pacakge. We
have the benefit of bytecompile and autoload
[packages] use new fetcher for local
This commit changes the yes-or-no-p to a read-answer with three options y, s and
n (for yes, some and no. This of course could be a, s, c for 'all',
'some/select' and 'cancel', but I decided to keep yes no as users are already
familiar with the y and n).
Finally the user can select packages by answer for each package in the list a
yes-or-no-p (pressing y or n, if you upgrade regularly the list usually is not
too long. It is anyway better than having only the options all or none).
The `nonc` construction is just a non cl alternative to cl-remove-if (I've added
the comment with the explanation).
From org version 9.5 org will not be distributed from Org ELPA but from
ELPA (see https://list.orgmode.org/87lfa7tc9v.fsf@gnu.org/t/). This commit makes
Spacemacs use/install org from ELPA.
Besides that, this commit removes some 'hack' that seemed to have no effect. As
org comes with Emacs `package-installed-p 'org` will always return t. Also
activating org via `configuration-layer//activate-package` seems to have no
effect.
Finally, the package is declared including a :min-version because appending only
`:location melpa` seems to have no effect (this can probably be considered a
bug).
I am almost certain that the information that was added when making org install
from Org ELPA is still relevant also for installing org from ELPA so I have just
adapted the version number from 0.104 to 0.300.
As the "org" archive has been removed, the `ert-deftest` for it can be removed
also.
problem:
`SPC f e U` checks if packages have updates.
But if the current buffer isn't the Spacemacs home buffer,
then the minibuffer just shows:
>Do you want to update 1 package(s)? (y or n)
There's no information about which packages have updates.
Canceling the prompt with: `n`
and switching to the messages buffer `SPC b m`, does list them.
>(Spacemacs) --> Found 1 package(s) to update:
>
>(Spacemacs) dap-mode
But it doesn't work to switch to the home buffer,
because that information was erased when the home buffer was refreshed.
solution:
Switch to the home buffer before checking for updates.
problem:
When the Emacs frame has the default window width (80 characters).
Then the current restart to update message:
Emacs has to be restarted to actually install the new version of the packages (SPC q r)
is cut off at the Emacs frames right edge:
Emacs has to be restarted to actually install the new version of the packages (S
solution:
Shortening the message:
Restart Emacs to install the updated packages. (SPC q r)
says the same thing, and keeps it within 80 characters.
Problem:
When the restart-emacs package is being updated.
The update packages restart message, still shows the (SPC q r) key binding even
though it doesn't work.
Cause:
The member function compared a string against a list of symbols.
A possible improvement:
Explain that the key binding won't work this time.
Before:
Emacs has to be restarted to actually install the new version of the packages (SPC q r).
After:
Emacs has to be restarted to actually install the new version of the packages
(SPC q r) won't work this time, because the restart-emacs package is being updated.
Added "configuration-layer//system-package?" based on package-delete
(pretty much a direct partial copy-paste) so that
"configuration-layer//package-delete" can check if package is a
system package
No crash on spacemacs boot (with unused system-package present).
Though right now "configuration-layer//package-delete" only ignores system
packages instead of reporting them. Not entierly what @nbraud proposed,
but insufficient err-logging is a significantly smaller issue.
Fixes#11160
- 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.
There was a edge case with the declaration of the `lsp` layer in `layers.el`
files.
The `hy` layer depends on the `python` layer which in turn depends on the `lsp`
layer if and only if the `python-backend` layer variable is set to `lsp`.
When the `hy` layer was declared first then it declares the `python` layer
without its layer variables, thus the `lsp` layer was not declared because the
`python-backend` variable was not set.
The fix is to gather all the layer dependencies and resolve them only after all
the used layers have been declared.
* new function `configuration-layer/declare-layer-dependencies`
* replace all calls to `configuration-layer/declare-layer` by the new function
except for distribution layers (we declare layer dependencies right away in
distribution layers)
* modified function configuration-layer//stable-elpa-verify-archive
Add a `fatal-err` variable to handle critical erros that prevent the
verification to be attempted.
Use the function `epg-verify-file` instead of `epg-verify-string` which seems
to give more reliable results.
* modified function configuration-layer//stable-elpa-verify-archive
Gather errors along the verification steps and make a single call to
configuration-layer//stable-elpa-ask-to-continue at the end of the function.
Improve the scope of catched errors so now the users should be prompted when
GPG is not available on the system.
* new function configuration-layer//stable-elpa-disable-repository
* new function configuration-layer//stable-elpa-update-version-file
* new function configuration-layer//stable-elpa-delete-temporary-files
* new function configuration-layer//stable-elpa-ask-to-continue
* new function configuration-layer//stable-elpa-verify-archive
* new function configuration-layer//stable-elpa-disable-repository
* rename function configuration-layer/stable-elpa-download-tarball to
configuration-layer//stable-elpa-download-tarball
* new function configuration-layer/stable-elpa-init
* make the function configuration-layer/stable-elpa-version interactive
configuration-layer/stable-elpa-init is called from init.el.
This function then calls the other new function in more clear fashion than the
previous complicated configuration-layer/stable-elpa-download-tarball
The users are now prompt if they want to install the stable ELPA repository when
the verification of the archive failed.
* new variable configuration-layer-stable-elpa-archive
* add missing sub-directory "packages"
* update .lock file with above changes and bump to archive version 0.400