New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

emacs-lisp-mode-hook shouldn't interfere with startup #219

Merged
merged 2 commits into from May 4, 2011

Conversation

Projects
None yet
2 participants
@glasserc
Contributor

glasserc commented May 4, 2011

Because of the collection of packages I have installed, emacs startup for me looks like this:

  • elisp mode customizations are made, including a hook to turn on paredit as part of elisp mode. paredit is not yet require'd, and its autoloads have not yet been loaded, because paredit is managed by el-get.
  • el-get installs/initializes a package. This requires byte-compiling (or generating autoloads). This process invokes emacs-lisp-mode.
  • emacs-lisp-mode-hook is run. A call is made to turn on paredit. emacs breaks.

In a perfect world, yes, emacs-lisp-mode customizations would be made after startup, and hooks would not be inserted when they could trigger errors. There are ways I could arrange the dependencies so that this situation would not come to pass. However, in the interests of the Principle of Least Surprise, I argue that the above is a bug.

It seems this is not a new problem. The byte-code-cache library on EmacsWiki contains code to disable emacs-lisp-mode-hook during byte-compiling. I believe this to be the simplest solution for my problem. Attached is a patch that does this when el-get byte-compiles a file.

I think reasonable people could disagree as to whether this is the most correct approach. Specifically:

  1. Is this going to surprise someone else later on? For example, is some emacs wizard going to put something in emacs-lisp-mode-hook that tweaks the process of byte-compiling or autoloading and then be surprised when it stops working? This is my biggest concern. I can't think of any use cases, but that doesn't mean there aren't any. I think if I were an emacs wizard I would prefer to use advice to tweak byte-compiling or autoloading instead of relying on an emacs-lisp-mode-hook.
  2. Assuming that, in fact, this won't surprise someone down the road, wouldn't it be better to do this in the emacs source that byte-compiles and generates autoloads instead of ad-hoc like this, in el-get as well as byte-code-cache and possibly elsewhere? The answer is probably yes but it's beyond my pay grade and besides I'm not an emacs wizard, and anyhow I don't want to have to wait for an emacs release cycle before I get this fixed.

In conclusion, I submit that the above patches (which disable emacs-lisp-mode-hook when manipulating autoloads/byte-compiling are good and should be applied.

Please apply.

Long-windedly yours,

Ethan

dimitri added a commit that referenced this pull request May 4, 2011

Merge pull request #219 from glasserc/master.
emacs-lisp-mode-hook shouldn't interfere with startup

@dimitri dimitri merged commit 80d2db9 into dimitri:master May 4, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment