8

This buffer annoys me every time I install a new package or update one with package.el:

screen-shot of the buffer

How can I tell to emacs that never ever show that buffer unless I need to know something really important from it?

  • 8
    You should not suppress it. It contains valuable information, highlight errors in the compilation process. – Andrew Swann Dec 22 '14 at 8:48
  • Agreed. You should rather bug maintainers to write warning-free code. – lunaryorn Dec 24 '14 at 11:49
  • Pradhan: Can't comment here yet, but the user didn't ask that there not be warnings. He asked that the frame with the warnings not open up. He may well want to review the compile log later. andrew-swann: You don't necessarily know what the user is trying to achieve. For example, I find popping open the buffer disrupts my flow. I found this thread because I was trying to install N packages, and I wanted to check the warnings at the end. What would be ideal would be to have the buffer pop up optionally, and display "N warnings, M errors" in the minibuffer. In any case, don't tell users who want – user3113723 May 12 '15 at 18:33
  • Customize display-buffer-alist? – politza May 12 '15 at 18:43
4

If your package--compile is calling byte-recompile-directory(default), you can turn off all warnings by customizing the variable byte-compile-warnings. You can either set it to nil yourself, or use M-x customize-group on the group bytecomp, set Byte Compile Warnings to Some and check none of the boxes. However, if you have package--compile being defadviced to invoke something else(async-byte-recompile-directory in my case), you should look into the customization of that specific function/library.

If you are using async-bytecomp, I have raised a request here to inject the bytecomp customizations into the environment it compiles in. You could make do with a local change until there's a resolution : Add

(async-inject-variables "\\`byte-compile-warnings\\'")

after

,(async-inject-variables "\\`load-path\\'")

in async-bytecomp.el.

1

From documentation:

set-window-dedicated-p is a built-in function in `C source code'.

(set-window-dedicated-p WINDOW FLAG)

Mark WINDOW as dedicated according to FLAG. WINDOW must be a live window and defaults to the selected one. FLAG non-nil means mark WINDOW as dedicated to its buffer. FLAG nil means mark WINDOW as non-dedicated. Return FLAG.

You may be interested by setting the installation window dedicated, then the compilation buffer will no more bother you when inside the dedicated window.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.