Add support for byte-compiling dot-emacs for package.el users

[errge]

For a bigger discussion on the problem I'm trying to solve and on my proposed solution, please see my article here: https://github.com/nilcons/emacs-use-package-fast

[basil-conto]

Quoting lambda is advised against.

[npostavs]

Just FYI, quoting with #' is okay, just redundant; it's quoting with ' that causes problems: it prevents compilation of the body and creation of closures when using lexical binding.

[errge]

Thanks for the clarification, will try to remember this! I like the #' quoting a lot, because it's nice for my eyes, even if it doesn't mean anything semantically.

[basil-conto]

Indentation is off here and below.

[errge]

@basil-conto Thank you for your review, I took your comments into consideration in my new version of the pull request: indentation should be fixed now, I'm not quoting the lambdas anymore.

[thomasf]

I found it more convenient to compile the load-path to it's own load-path.el to avoid having to recompile init.el when packages are upgraded.

[thomasf]

The performance hit of checking that all directories in the compiled load path exists was low enough to have as well so load-path.el can recompile itself on start up if packages are missing (usually means upgraded)

https://github.com/thomasf/dotfiles-thomasf-emacs/blob/master/emacs.d/load-path.el#L90

[thomasf]

The main reasons for not having made my load-path.el into a installable package is that it doesnt handle info and theme paths automatically. If it were a package I would also expect that additional user defined paths would be supported via defcustoms.

[errge]

I will definitely contribute something for the info situation, as I already mentioned in my blog post.

I can work on the theme-paths too.

I first wanted to see if there is willingness to merge package.el supports like this. To test the waters, I started with load-path, because this solves I think 95% of the problem.

If you are only willing to merge this when it gets info dir support, I can do that quickly. If you require theme-path support too, then I have to look into themes, I never used them, but I'm willing to.

What's your opinion?

[errge]

Or are you saying that I should add a safety check mechanism to automatically realize when my compiled part of .emacs needs recompilation? I can also add that if you think that's important for the end-users.

Should I implement the check simply with comparing my compilation time to the package-user-dir mtime (every new install, removal or upgrade will modify that) or do you want to keep your logic of checking for deleted directories? I'm OK with both.

[errge]

Personally, I think your load-path.el solution is very clever and my whole project started with reading your code and starting out from that, so huge thank you for that! I don't want that to be the official solution though, because I think the extra file and added complexity will make it harder for new people to understand it and deploy in their environment.

I was shooting for something that we can document as a pattern in the README.md and works well for the average use-package+package.el user without too much hassle, while still achieving very good performance. In that respect, I think even saying that you have to recompile your .emacs after package upgrades is OK, but maybe we should have the problem autodetection+warning in my generated code.

[errge]

@thomasf ping

[stevenspasbo]

Typo here

[errge]

Thanks for catching this, pushed a fix!

[jwiegley]

My inclination is to ask that this be maintained as a separate project, but with a change to our README that recommends users to reference that project as a solution for those who wish to compile their init.el.

I stopped compiling my init.el because it doesn't have enough impact on startup for the additional complexities it introduces.

[errge]

@jwiegley I understand your point of a separate project, but I'm afraid that by doing it that way, it will be way less likely for people to try it out and to contribute with ideas if needed in the future.

Note, that my proposed solution also neatly provides a way for the user to not call package-initialize when she is using byte compiled dot-emacs, and these two changes together result in meaningful startup impact. I think you don't see an impact, because you never used package-initialize from package.el.

So how I see my patch is exactly what you suggest: more a knowhow documentation than code, because I provide a way to use package.el and use-package together to achieve very good startup time even with a lot of easy to install packages from melpa.

This is why in my patch I only provide one new macro which is never called from other parts of use-package, and this is why I provide a lot of documentation. Are you against this additional macro even though it's totally separated and isolated from the rest of use-package?

If the answer is still "yes, we are against it", I can understand, but can we still negotiate a way out of creating yet another project? You mentioned that you would be open to reference my proposed solution. If you reject the addition of the one defmacro, is it OK for you if I just inline it into the documentation? So I remove the defmacro from my pull request, but I change the README example to have everything needed (basically the macro call inlined), therefore providing the user with a solution that she can copy-paste as a starting dot-emacs. My estimate that this example barebone dot-emacs would be around 15-20 lines and not too hard to understand. The defmacro just made it shorter a little bit, but it's not needed for my solution.

Thanks for your consideration and best regards in the hope of integrating my solution some way into use-package, instead of starting yet another project.

[jwiegley]

The line really has to be drawn somewhere. In fact, I'd like to move everything package.el related to a separate package, so use-package.el becomes more of a core library than a "do all be all".

As for lack of advertizing if we don't include something in either the code or the docs: This isn't really the place for that. Adding it to use-package.el means it needs to be documented, supported, and that issues come here first. I've specifically designed use-package.el to be extensible, so that additional features like this are easily added and maintained outside the core functionality.

I'm happy to reference your project within the README, but I'd prefer not to include the actual macro at this time.

[thomasf]

Sorry for a late reply.. I agree that this does not have to be inside
use-pacakage at all.

I think that this feature should be a package published as it's own
package.el package rather than just being a guide.

Byte compiling is one way to do it, a m slightly simpler alternative to byte
compiling could maybe be to just save it in a file somewhere, It would probably
still be faster than doing the package.el init thing on start up but it needs
to be tested. That file could of course still be an elisp file which can be
byte compiled but fully maintained by the package, just need some sane way to
locate and update it.

We could maybe continue the discussion somewhere else but I don't currently
have much time for this.