pierre-rouleau/pel

Emacs 27 support for fast startup broken

Closed this issue · 7 comments

pierre-rouleau commented
Emacs 27 support for fast startup broken
pierre-rouleau commented

packages in the pel-bundle are not handled properly on Emacs 27.1, on a Fedora system.

pierre-rouleau commented

This is a strange issue. The failure occurs on a Fedora 32 VM running Emcas 27.1.
However, all is fine with the same (not yet checked in) code running on macOS Mojave on both Emacs 27.1 graphics and Emacs 27.2 terminal...

Still investigating.

pierre-rouleau commented

On the other hand, the 2 computers use different settings. On Fedora 32 VM Emacs 27.1, PEL is not using dual environment.

  • On macOS Mojave Emacs 27.[12] PEL is using dual environment but it's not complete and not active.
  • The init.el file is different, using the old init-5.el. I updated the file: Mojave still runs file.
  • the pelfast-startup-init.el is different. Fedora uses the new one, Mojave the old. Updated Fedora with the new on: PEL still works fine.
  • Mojave also does not use an early-init.el file but Fedora uses the latest template of early-init. I copied the early-init.el into Mojave ~/.emacs.d and Mojave still works fine.
    • However the load-path when early-init.el is used has an extra entry for pel-bundle from elpa-reduced identified as the true name as opposed to all others that are using the 'elpa' symlink. The extra entry is most probably created by Emacs running after the early-init. That needs investigation. Looking into this now.

I will try macOS PEL without dual env to see if it fails too.

pierre-rouleau commented

It looks like the issue has to do with the layout of the ~/.emacs.d directory which became invalid following some failure tests and PEL logic is not able to report precisely the problem. Still investigating.

pierre-rouleau commented

This however has identified that pel-fast-startup-init.el generated code should use 'elpa' as opposed to 'elpa-reduced' or 'elpa-complete' as the elpa directory name of the directory where pel-bundle is located, to use the same format as used in other PEL logic and prevent duplication. Another possibility might be to not add pel-bundle inside pel-startup-fast-init.el.

pierre-rouleau commented

Another issue has to do with the code gemnerated fpr pel-fast-startup-init: the second step is required only when package-quickstart is used.

pierre-rouleau commented

Fixed with the latest commits