all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#19514: 25.0.50; byte-compile-file too tight-lipped
@ 2015-01-05 11:10 Katsumi Yamaoka
  2015-01-06 23:30 ` Paul Eggert
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Katsumi Yamaoka @ 2015-01-05 11:10 UTC (permalink / raw)
  To: 19514

Hi,

The byte compiler is now too quiet if it runs in the batch mode.
For instance, this is what I got when compiling Ma Gnus:

[...]
lispdir="/usr/local/share/emacs/25.0.50/site-lisp/gnus" srcdir=. emacs-25.0.50 -batch -q -no-site-file -l /usr/local/share/emacs/site-lisp/no-site-lisp.el -l ./dgnushack.el -f dgnushack-compile
No MH variant found on the system
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
Warning: Using brain-dead macro `mm-with-unibyte-current-buffer'!
[...]

I cannot see what Lisp modules are blamed.  This seems to be due
to the recent change <cd2d58c1c81d608d6e1aefe1eb8a3d1f1cd60540>.

Thanks.

In GNU Emacs 25.0.50.1 (i686-pc-cygwin, GTK+ Version 3.10.9)
 of 2015-01-05 on localhost
Windowing system distributor `The Cygwin/X Project', version 11.0.11501000
Configured using:
 `configure --verbose --with-x-toolkit=gtk3'





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#19514: 25.0.50; byte-compile-file too tight-lipped
  2015-01-05 11:10 bug#19514: 25.0.50; byte-compile-file too tight-lipped Katsumi Yamaoka
@ 2015-01-06 23:30 ` Paul Eggert
  2015-01-07  3:43 ` Katsumi Yamaoka
  2015-01-20  0:02 ` Katsumi Yamaoka
  2 siblings, 0 replies; 5+ messages in thread
From: Paul Eggert @ 2015-01-06 23:30 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: 19514

[-- Attachment #1: Type: text/plain, Size: 267 bytes --]

Hmm, well, dgnushack shouldn't rely on byte-compile-file outputting 
messages when not verbose.  One way to fix this is for dgnushack to set 
byte-compile-verbose, but that might make dgnushack *too* verbose.  So 
how about the attached patch to dgnushack instead?



[-- Attachment #2: gnus.diff --]
[-- Type: text/x-patch, Size: 1843 bytes --]

diff --git a/lisp/dgnushack.el b/lisp/dgnushack.el
index 9d862bd..237fbef 100644
--- a/lisp/dgnushack.el
+++ b/lisp/dgnushack.el
@@ -272,6 +272,11 @@ in `defcustom' forms."
 		 (equal (nth 1 form) ''nconc))
 	(setq form (cons 'mapcan (cdr last)))))))
 
+(defun dgnushack-compile-file (file)
+  "Byte-compile FILE after reporting that it's being compiled."
+  (message "Compiling %s..." file)
+  (byte-compile-file file))
+
 (defun dgnushack-compile-verbosely ()
   "Call dgnushack-compile with warnings ENABLED.  If you are compiling
 patches to gnus, you should consider modifying make.bat to call
@@ -349,10 +354,10 @@ This means that every warning will be reported as an error."
 	(if error-on-warn
 	    (let ((byte-compile-error-on-warn t))
 	      (unless (ignore-errors
-			(byte-compile-file file))
+			(dgnushack-compile-file file))
 		(setq compilesuccess nil)))
 	  (ignore-errors
-	    (byte-compile-file file)))))
+	    (dgnushack-compile-file file)))))
     compilesuccess))
 
 (defun dgnushack-recompile ()
@@ -383,8 +388,7 @@ This means that every warning will be reported as an error."
 	  (Custom-make-dependencies))
       (ad-unadvise 'directory-files))
     (when (featurep 'xemacs)
-      (message "Compiling %s..." dgnushack-cus-load-file)
-      (byte-compile-file dgnushack-cus-load-file))))
+      (dgnushack-compile dgnushack-cus-load-file))))
 
 (defun dgnushack-make-auto-load ()
   (require 'autoload)
@@ -455,8 +459,7 @@ This means that every warning will be reported as an error."
 ;;; gnus-load.el ends here
 ")
       ))
-  (message "Compiling %s..." dgnushack-gnus-load-file)
-  (byte-compile-file dgnushack-gnus-load-file)
+  (dgnushack-compile-file dgnushack-gnus-load-file)
   (when (featurep 'xemacs)
     (message "Creating dummy gnus-load.el...")
     (with-temp-file (expand-file-name "gnus-load.el")

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* bug#19514: 25.0.50; byte-compile-file too tight-lipped
  2015-01-05 11:10 bug#19514: 25.0.50; byte-compile-file too tight-lipped Katsumi Yamaoka
  2015-01-06 23:30 ` Paul Eggert
@ 2015-01-07  3:43 ` Katsumi Yamaoka
  2015-01-07  7:04   ` Paul Eggert
  2015-01-20  0:02 ` Katsumi Yamaoka
  2 siblings, 1 reply; 5+ messages in thread
From: Katsumi Yamaoka @ 2015-01-07  3:43 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 19514

On Tue, 06 Jan 2015 15:30:51 -0800, Paul Eggert wrote:
> Hmm, well, dgnushack shouldn't rely on byte-compile-file outputting
> messages when not verbose.  One way to fix this is for dgnushack to
> set byte-compile-verbose, but that might make dgnushack *too* verbose.
> So how about the attached patch to dgnushack instead?

[...]
> +(defun dgnushack-compile-file (file)
> +  "Byte-compile FILE after reporting that it's being compiled."
> +  (message "Compiling %s..." file)
> +  (byte-compile-file file))
[...]

It will work.  Thanks.  But should every Lisp package, that uses
byte-compile-file, have such one in its install program?
Even if a Lisp package is perfect and issues no warning (the CVS
HEAD of emacs-w3m is it), the installer had better say at least
"Wrote xxx.elc" rather than no message is displayed for a couple
of ten seconds, I think.  How about this?

(defvar byte-compile-silent nil
  "*If non-nil, byte-compiler issues no verbose message in the batch mode.")

I hope it defaults to nil, i.e. the default behavior is unchanged.





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#19514: 25.0.50; byte-compile-file too tight-lipped
  2015-01-07  3:43 ` Katsumi Yamaoka
@ 2015-01-07  7:04   ` Paul Eggert
  0 siblings, 0 replies; 5+ messages in thread
From: Paul Eggert @ 2015-01-07  7:04 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: 19514

Katsumi Yamaoka wrote:
> How about this?
>
> (defvar byte-compile-silent nil
>    "*If non-nil, byte-compiler issues no verbose message in the batch mode.")

That would be doable, but the value of doing it seems limited, as the caller of 
byte-compile-file can easily write the message itself.  This distinguishes it 
from byte-compile-verbose, which cannot be easily implemented by a wrapper.

Furthermore, the old behavior was not good.  First one saw the error messages 
from compiling FOO.  Then one saw the message saying that FOO was compiled. 
That's backwards and confusing.

So I'd prefer fixing dgnushack to generate better output.  Similarly for any 
other callers relying on the old "Wrote" message (my impression is that most 
callers won't care).





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#19514: 25.0.50; byte-compile-file too tight-lipped
  2015-01-05 11:10 bug#19514: 25.0.50; byte-compile-file too tight-lipped Katsumi Yamaoka
  2015-01-06 23:30 ` Paul Eggert
  2015-01-07  3:43 ` Katsumi Yamaoka
@ 2015-01-20  0:02 ` Katsumi Yamaoka
  2 siblings, 0 replies; 5+ messages in thread
From: Katsumi Yamaoka @ 2015-01-20  0:02 UTC (permalink / raw)
  To: Paul Eggert; +Cc: 19514-done

I've installed your `dgnushack-compile-file' for only GNU Emacs
after all.  Thanks.

<http://article.gmane.org/gmane.emacs.gnus.cvs/12738>





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-01-20  0:02 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-05 11:10 bug#19514: 25.0.50; byte-compile-file too tight-lipped Katsumi Yamaoka
2015-01-06 23:30 ` Paul Eggert
2015-01-07  3:43 ` Katsumi Yamaoka
2015-01-07  7:04   ` Paul Eggert
2015-01-20  0:02 ` Katsumi Yamaoka

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.