[PATCH 6/7] Small changes

[PATCH 6/7] Small changes

[Xavier Maillard]

* Makefile: add git-blame as a candidate to the
  byte-compilation. Change the function to call to byte-compile.

Signed-off-by: Xavier Maillard <zedek@gnu.org>
---
 contrib/emacs/Makefile |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/contrib/emacs/Makefile b/contrib/emacs/Makefile
index 350846d..8554e39 100644
--- a/contrib/emacs/Makefile
+++ b/contrib/emacs/Makefile
@@ -2,7 +2,7 @@
 
 EMACS = emacs
 
-ELC = git.elc vc-git.elc
+ELC = git.elc vc-git.elc git-blame.elc
 INSTALL ?= install
 INSTALL_ELC = $(INSTALL) -m 644
 prefix ?= $(HOME)
@@ -15,6 +15,6 @@ install: all
 	$(INSTALL_ELC) $(ELC) $(emacsdir)
 
 %.elc: %.el
-	$(EMACS) --batch --eval '(byte-compile-file "$<")'
+	$(EMACS) -batch -f batch-byte-compile $<
 
 clean:; rm -f $(ELC)
-- 
1.5.0

Re: [PATCH 6/7] Small changes

[Junio C Hamano]

Xavier Maillard <zedek@gnu.org> writes:

> * Makefile: add git-blame as a candidate to the
>   byte-compilation. Change the function to call to byte-compile.

Could we have a bit more detailed description on the latter
change?

Explaining why something needed a change is the point of a
commit log message.  Summarizing what got changed and how is
good but that is secondary, because anybody can see that you
changed the handcrafted --eval to -f by running "git show", even
if you did not have the above proposed log message.

What is left unsaid is _why_ it is better to use single dash
form of "-batch" and -f form instead of handcrafted --eval, and
the proposed log message does not clarify the reason.

>  %.elc: %.el
> -	$(EMACS) --batch --eval '(byte-compile-file "$<")'
> +	$(EMACS) -batch -f batch-byte-compile $<
>  
>  clean:; rm -f $(ELC)

Re: [PATCH 6/7] Small changes

[Xavier Maillard]

   From: Junio C Hamano <junkio@cox.net>

   Xavier Maillard <zedek@gnu.org> writes:

   > * Makefile: add git-blame as a candidate to the
   >   byte-compilation. Change the function to call to byte-compile.

   Could we have a bit more detailed description on the latter
   change?

Sure.

byte-compile-file is an interactive function.
batch--byte-compile is a batch function.

First function would be (better) called when using emacs in its
"interactive" form -ie. M-x byte-compile-file RET.

batch-byte-compile is reserved for batching use (no interaction
with the user).

So in non interactive mode, this is prefered way to do things.

   Explaining why something needed a change is the point of a
   commit log message.  Summarizing what got changed and how is
   good but that is secondary, because anybody can see that you
   changed the handcrafted --eval to -f by running "git show", even
   if you did not have the above proposed log message.

Sorry Iam not "good" at commit log :/ 

   What is left unsaid is _why_ it is better to use single dash
   form of "-batch" and -f form instead of handcrafted --eval, and
   the proposed log message does not clarify the reason.

First reason is given by C-h f batch-byte-compile RET which
gives:

batch-byte-compile is an autoloaded Lisp function in `bytecomp'.
(batch-byte-compile &optional noforce)

Run `byte-compile-file' on the files remaining on the command line.
Use this from the command line, with `-batch';
it won't work in an interactive Emacs.
Each file is processed even if an error occurred previously.
For example, invoke "emacs -batch -f batch-byte-compile $emacs/ ~/*.el".
If noforce is non-nil, don't recompile a file that seems to be

Second reason is "by habit" :)


Hope Ihave been clear. If you want me to submit something again
from these patches, please tell how to do so (and modify what
Ihave changed).

-- 
Xavier

Re: [PATCH 6/7] Small changes

[Junio C Hamano]

Xavier Maillard <zedek@gnu.org> writes:

>    From: Junio C Hamano <junkio@cox.net>
>
>    Xavier Maillard <zedek@gnu.org> writes:
>
>    > * Makefile: add git-blame as a candidate to the
>    >   byte-compilation. Change the function to call to byte-compile.
>
>    Could we have a bit more detailed description on the latter
>    change?
>
> Sure.
> ...
> Hope Ihave been clear.

Thanks.  Received your other message and will apply.