Chemacs 2

[JacekHoleczek]

Chemacs 2

[abougouffa]

Hello @JacekHoleczek

Thanks for bringing this to my attention,

I've pushed a commit which hopefully will fix this. I've tested it with the same steps you've described.

Can you confirm if it works as expected?

[JacekHoleczek]

The brutal "bootstrapping" approach, which uses the "~/.emacs.el" file, still does not work.
It dies, reporting that it cannot open load file "~/.emacs.d/core/me-vars.el".

The Chemacs 2 method, which uses the "~/.emacs-profiles.el" file, seems to work.
In the end, it reported some strange "timer" error, though (also note that it asked to download the "Emoji images" twice, and I had to press "y" twice):

(...)
[emojify] Emoji images not available should I download them now? (y or n) y
Wrote /tmp/emojifylUagfi
Parsing tar file...done
Extracting...done
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

 11 3052k   11  351k    0     0   408k      0  0:00:07 --:--:--  0:00:07  408k
100 3052k  100 3052k    0     0  3178k      0 --:--:-- --:--:-- --:--:-- 26.3M
Installing parinfer-rust-linux.so v0.4.4-beta to ~/.minemacs.d/.emacs.d/local/parinfer-rust/parinfer-rust-linux.so
[emojify] Emoji images not available should I download them now? (y or n) y
Contacting host: raw.githubusercontent.com:443
Wrote /tmp/emojifyFqUzFQ
Parsing tar file...done
Extracting...done
Error running timer: (wrong-type-argument timerp nil)

From my previous trials (I was playing with "user-emacs-directory", "MINEMACS_DIR" and even "HOME"), I noticed that the ".../my/directory/" names had to end with the "/" character (or the MinEmacs misbehaved, e.g., trying to access ".../my/directorycore/..." instead of ".../my/directory/core/...").
This is something that other profiles do not need (directory names are given without the trailing "/"), so maybe you could have a look at it, too.

Last but not least, I would also like to propose that the "MINEMACS_DIR" is renamed into "MINEMACSDIR".
This is to make its name "consistent" with other profiles which use a similar approach, e.g., "SPACEMACSDIR" and "DOOMDIR".

[JacekHoleczek]

A small update ...

I decided to try it from scratch again (i.e., I removed the "~/.minemacs.d").
This time, it asked to download the "Emoji images" just once and there was no "timer" error.

Well, I forgot to report something slightly worrying ...
When installing, the MinEmacs creates an empty "~/.emacs.d/snippets" directory (well, it should NOT touch "~/.emacs.d" at all).
It seems that this happens when it downloads and installs the "yasnippet-snippets" or the "doom-snippets".

[abougouffa]

Hello @JacekHoleczek, thank you for the feedback!

I'm using MinEmacs with Emacs 30 (built from source), the emojify config is used only on version 28, as Emacs 29+ have native emoji support (not configured perfectly ATM).

I've just pushed a commit to suppress the annoying emojify confirmation, I guess this could fix the timer error too, as emojify is lazy loaded at startup (which loads packages inside run-with-idle-timer).

For the brutal bootstrapping approach, I think there is a small issue with the current Chemacs2 implementation. When I tested it a VM, I got this:

Warning (initialization): An error occurred while loading ‘/home/vm/.emacs.d/early-init.el’:

error: [chemacs] ~/.emacs-profiles.el does not exist.

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace. Disable showing Disable logging
Warning (initialization): An error occurred while loading ‘/home/vm/.emacs.el’:

File is missing: Cannot open load file, No such file or directory, ~/.emacs.d/core/me-vars.el

To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file.  Start Emacs with
the ‘--debug-init’ option to view a complete error backtrace. Disable showing Disable logging

This seems to be a problem with Chemacs2. Lets me explain: because ~/.emacs.d/early-init.el exists, Emacs will first set user-emacs-directory to ~/.emacs.d/ and load ~/.emacs.d/early-init.el, and then, instead of loading ~/.emacs.d/init.el it loads the prioritized file ~/.emacs.el.

This seems to me a bit awkward (in my machine, I removed ~/.emacs-profiles.el and got the error above). The last commits should make Emacs happy (loads correctly without me-vars.el issue), however, loading Emacs this way it will miss the options set in MinEmacs' early-init.el (because it will load Chemacs' one instead).

I agree on the MINEMACSDIR part, now both MINEMACSDIR and MINEMACS_DIR are valid env vars, I kept the old one for backward compatibility.

[abougouffa]

The issue with snippets directory should be fixed also (I had other directories showing around like transient/ and pcache/). Although, I think you will get occasionally some random directories in the .emacs.d/, because before, I was setting user-emacs-directory explicitly to minemacs-local-dir, but it seems that Chemacs2 is not OK with it!

[abougouffa]

@JacekHoleczek Can you try to pull the latest commits and try again?

[JacekHoleczek]

Great!

The download the "Emoji images" confirmation is gone.

It seems that the "~/.emacs.d/snippets" directory is always created, when the "yasnippet-snippets" or the "doom-snippets" are being worked on, regarless of the "bootstrapping" approach.

One gets new errors now, whenever one runs emacs (which maybe suggest that the above problem is related to "yasnippet-...", not "doom-..."):

[yas] Check your `yas-snippet-dirs': ~/.minemacs.d/snippets/ is not a directory [3 times]
[yas] Prepared just-in-time loading of snippets with some errors.  Check *Messages*.

Except for the above problems, I can confirm that the Chemacs 2 approach works now.

When trying the brutal "bootstrapping" approach ... I forgot that it will unconditionally execute the "~/.emacs.d/early-init.el" before the "~/.emacs.el".
The solution is simple.
Either (it seems that the "-q" option is not needed):

MINEMACSDIR="${HOME}/.minemacs.d/" emacs --eval='(load-file "~/.minemacs.d/.emacs.d/init.el")'

or:

mv ~/.emacs.d ~/.emacs.d.hidden # we need to "hide" it
echo '(load-file "~/.minemacs.d/.emacs.d/init.el")' > ~/.emacs.el
MINEMACSDIR="${HOME}/.minemacs.d/" emacs

[abougouffa]

Thanks for the confirmation @JacekHoleczek

I guess the last commit should fix the snippets' error (by ensuring the directory exists, and create it if not).

[JacekHoleczek]

Almost perfect.

It still creates the spurious "~/.emacs.d/snippets" directory.

And it now also creates the "~/.minemacs.d/snippets" directory, so the error is gone.
Is this directory supposed to "replace" the original "~/.emacs.d/snippets" directory?
If yes, maybe it should create "~/.minemacs.d/.emacs.d/snippets" instead?
So, "(user-emacs-directory)/snippets" instead of "$MINEMACSDIR/snippets".

[abougouffa]

I wonder why you still have the ~/.emacs.d/snippets/ directory! I cannot reproduce it on my machine!

For the second point, in fact, MinEmacs (a bit like Doom or Spacemacs) should reside in ~/.emacs.d (or any other equivalent directory), and the ~/.minemacs.d/ (a bit like ~/.doom.d/ or ~/.spacemacs.d/) should contain user config files (config.el, modules.el, early-config.el, ...). The snippets directory is supposed to include the user defined snippets, so logically it should reside in the user config directory.

[JacekHoleczek]

I suspect that the described "snippets" directory problems are "interconnected".

I tried the "canonical" way of installing MinEmacs:

rm -rf ~/.emacs.el ~/.emacs ~/.emacs.d
rm -rf ~/.minemacs.d
git clone --depth 1 https://github.com/abougouffa/minemacs.git ~/.emacs.d
emacs

Quite early in the "bootstrap", it also creates the empty "~/.emacs.d/snippets" directory, either when processing the "yasnippet-snippets" or the "doom-snippets" (judging from the printed output in the "echo area" line in the bottom of the emacs frame, but I don't know how much "delay" this printout has).
However, at that moment, the user config directory "~/.minemacs.d" is not present at all.
It is first created at the very end of the "bootstrap" (and then there immediately appears the empty "~/.minemacs.d/snippets" directory, too).

So, maybe the problem is that because the user snippets directory does not exist in "~/.minemacs.d/", the "bootstrap" creates a default one in "~/.emacs.d/".
Or maybe it simply disregards the "user config" at that moment (early in the "bootstrap").

[JacekHoleczek]

I noticed another funny quirk in the "bootstrap".

The first time I start "emacs", it automatically enters the "bootstrap".
I then move my "mouse focus" to work in another window(s).
The "bootstrap" continues but only until I see "Installing parinfer-rust-linux.so v0.4.4.-beta ...".
As soon as this line is printed (in the "echo area" line at the bottom of the emacs frame), it "hangs".
It simply waits for the "mouse focus". I need to move my mouse to the "emacs frame" and then it magically continues with downloading the "Emoji images" until it prints "Extracting...done".
Then, if I do nothing, it "hangs" again.
First when I move my "mouse focus" to another window and then back to the "emacs frame", it continues, and it finally creates the user config "~/.minemacs.d/" directory) (the "Extracting...done" line is still visible).

If it matters, my "emacs" is actually the "emacs-lucid", built on Ubuntu 22.04 / x86_64 / gcc 11.3.0 from an up-to-date emacs-28 branch source code.

[abougouffa]

Hello @JacekHoleczek

Thanks again for the feedback,

I refactored yesterday's code and added a way to ensure (in most of the cases) that the directories gets created in the right place (in minemacs-local-dir).

For the focus issue, I've noticed it as well, but I didn't dig deeper since it is not a fatal issue.

It happens when loading lazy packages (loaded after startup when Emacs goes idle), it seems that Emacs' run-with-idle-timer behaves strangely when called in such a context. I will try to investigate this when I get some free time.

In the meanwhile, I think with la latest commits, all the blocking issues are fixed.

[JacekHoleczek]

I've redone the "canonical" test. Before starting "emacs", I first ran "mkdir -p ~/.minemacs.d/snippets". It didn't help. It still created the "~/.emacs.d/snippets" (at the same time as previously).
So, it seems it disregards the "user config" at that moment (early in the "bootstrap").

[abougouffa]

I've tested it on a VM with Emacs 28 on Ubuntu, I got the same effect! The snippets' directory is created at startup. I tried to force yasnippet (which is causing the creation of the directory) to use another path, but it still creates it (when byte-compiling the package).

I don't understand why it is created even when the variable is overwritten!

I will try to take a look at it when I get some free time.

[JacekHoleczek]

A small note ... I tried the current version, and it didn't create the "~/.minemacs.d" (I ran "emacs" several times).

[abougouffa]

Yep, I reverted the creation of ~/.minemacs.d/snippets. There is no real benefit from creating the snippets directory unless the user adds some custom snippets inside it.