zenburn-theme is not available in MELPA now about zenburn-emacs

[bbatsov]

I'll have a look. Maybe some of @tarsius's recent changes have caused some problem and the package cannot be automatically built? @purcell Is there some MELPA log for packages that couldn't be built?

[purcell]

Looks like you've got some weird compile-time dependency on rainbow-mode, possibly due to a .dir-locals.el file which MELPA encounters as it reads the source files:

Symbol's function definition is void: zenburn-turn-on-rainbow-mode

[purcell]

(You can test it by checking out MELPA, opening the zenburn recipe and entering C-c C-c.)

[purcell]

Yeah, it's that Local Variables block. It says to eval the rainbow-mode function when the file is opened, but of course that function may not even be defined.

What you want instead is:

;; Local Variables:
;; no-byte-compile: t
;; indent-tabs-mode: nil
;; rainbow-mode: t
;; End:

[bbatsov]

Will this work if rainbow-mode is not installed?

[purcell]

Yes. In that case, it's effectively just setting an undefined variable.

[tarsius]

rainbow-mode is enabled like this:

;;;###autoload
(defun zenburn-turn-on-rainbow-mode ()
  "Turn on Rainbow mode if it is available."
  (when (require 'rainbow-mode nil t)
    (rainbow-mode 1)))

....

;; Local Variables:
;; no-byte-compile: t
;; indent-tabs-mode: nil
;; eval: (zenburn-turn-on-rainbow-mode)
;; End:

I cannot see how that is supposed to fail when rainbow-mode is not available. Library rainbow-mode is soft required, and if it cannot be found the mode function rainbow-mode isn't called. Am I missing something here?

I did not call rainbow-mode directly because then users who do not have it installed would get a warning about unsafe forms. So this is a convenience things - if it is causing problems then it should be removed as it fails to serve it's purpose. :-)

Also maybe you (@purcell) could disable file local variables during builds on melpa; similar issues could arise in other packages. Does build failure remove a package? Wouldn't it make more sense to just keep the previous version?

[tarsius]

(Aren't we all just super maintainers, so quick to respond, group-pat-on-shoulders :-)

[purcell]

The removal of the package is an issue we need to look into. The intended behaviour is of course to keep the previous version.

Regarding the variable question, I believe the behaviour we specify when opening the files is to enable only safe local variables, so rainbow-mode: t would be ignored. However, the eval seems to be applied, which is obviously bad for us, so I'll look into that too.

[purcell]

And yes, we've all clearly got nothing better to do than hack on elisp. ;-)

[tarsius]

When I originally enabled rainbow-mode rainbow-mode: t was exactly what I did (If I remember correctly). Someone else introduced the code reintroduced in the temporary fix referenced above (which I have also commented on).

[tarsius]

Except for us not getting paid there is nothing wrong with hacking on elisp oO

[purcell]

@tarsius My boss (me) currently seems to pay me the same whatever I spend my time hacking on. But that observation might not turn out to be accurate in the longer term. ;-)

[shiquanwang]

Glad this issue receives so rapid response and triggers other improvements.
Thank you all for your work.

[bbatsov]

It was actually eval: (rainbow-mode +1) that was blowing up if I recall correctly. :-)

Cheers,
Bozhidar

On Monday, May 13, 2013 at 5:46 PM, Jonas Bernoulli wrote:

When I originally enabled rainbow-mode rainbow-mode: t was exactly what I did (If I remember correctly). Someone else introduced the code reintroduced in the temporary fix referenced above (which I have also commented on).

—
Reply to this email directly or view it on GitHub (#107 (comment)).

[milkypostman]

@bbatsov the problem is that (zenburn-turn-on-rainbow-mode) is getting eval'd when the buffer is loaded into Emacs, but it doesn't mean that the file itself is being loaded. I.e., just because I load a file into a buffer doesn't mean that it's getting eval'd. So regardless of the MELPA errors, this eval will cause problems.

[tarsius]

That I used because info emacs "Specifying File Variables" sais:

Do not use the `mode' keyword for minor modes.  To enable or disable
a minor mode in a local variables list, use the `eval' keyword with a
Lisp expression that runs the mode command.

Just setting the mode variable to non-nil might work for some minor modes but for others (most?) calling the mode function is the only way to go.

[milkypostman]

would it be better to eval (when (boundp 'rainbow-mode) (rainbow-mode t))

[tarsius]

So Emacs support for enabling minor modes that might not be available in the local variable section is poor. I tried hacking around it... and now we are paying the price :-/

@milkypostman yes I think this is best:

;;;###autoload
(add-to-list 'safe-local-eval-forms '(when (require 'rainbow-mode nil t) (rainbow-mode 1)))

;; Local Variables:
;; eval: (when (require 'rainbow-mode nil t) (rainbow-mode 1))
;; End:

[milkypostman]

@tarsius Interesting in the docs. Yes, your example looks correct. great

[tarsius]

@bbatsov Also now that there is actual code in the file wouldn't it be better to remove no-byte-compile: t? Why was that added in the first place?

[bbatsov]

@tarsius To be honest - I don't remember. It's possible someone has contributed it at some point, since I rarely add Local Variables myself (except to suppress cl warnings in the past).

[tarsius]

Why are we doing this in the first place:

[tarsius]

@bbatsov I ported all my code to cl-lib (I think) and added this to my init.el:

;; * There is no let like flet.

;; As long as many built-in libraries use `flet' I don't think
;; there is anything wrong with this.  I hope that by the time
;; the next version is released either this macro isn't declared
;; obsolete anymore or a proper replacement is available.

;; It's a bit silly but note that in files in which you use
;; `flet' you now have to "require cl" like this:
;;
;;   (require 'cl-lib)
;;   (eval-when-compile (require 'cl)) ; flet

(put 'flet 'byte-obsolete-info nil)