bug#33602: 27.0.50; Compiling no file at

bug#33602: 27.0.50; Compiling no file at

[Markus FFM]

(is that a late April Fools' Day prank?)
after each restart, a *Compile-log* buffer reports
Compiling no file at <any date>


In GNU Emacs 27.0.50 (build 20, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
 of 2018-12-03 built on INDRA
Repository revision: e5634aae531ce932ecb8d84243d690c7ca89bec3
Repository branch: master
Windowing system distributor 'Fedora Project', version 11.0.12003000
System Description: Fedora 29 (Twenty Nine)

Recent messages:
>>>load time: Monday, December  3, 2018 20:15:49<<<
>>>activated: themes<<<
Desktop: 1 buffer restored.
Loading /root/.emacs.d/framegeometry...done
For information about GNU Emacs and the GNU system, type C-M-h C-a.
Making completion list...
smooth-scroll/.vscroll-aux: Beginning of buffer
Making completion list...
Quit
Making completion list...

Configured using:
 'configure --prefix=/opt/emacs --sysconfdir=/etc
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --libexecdir=/opt/emacs/lib/ --localstatedir=/usr/local/var
 --enable-largefile --with-x-toolkit=gtk3 --with-sound=no --with-modules
 --with-xwidgets --without-pop --without-selinux --without-gnutls
 --disable-acl --with-file-notification=yes --with-json --without-xml2
 --without-libgmp 'CFLAGS=-march=native -Os''

Configured features:
XPM JPEG TIFF GIF PNG RSVG GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM
MODULES THREADS XWIDGETS LIBSYSTEMD JSON

Important settings:
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  recentf-mode: t
  desktop-save-mode: 1
  global-hl-line-mode: t
  delete-selection-mode: t
  cua-mode: t
  savehist-mode: t
  global-auto-revert-mode: t
  auto-insert-mode: t
  tabbar-mwheel-mode: t
  tabbar-mode: t
  smooth-scroll-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  save-place-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-quote-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  global-prettify-symbols-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader jka-compr info
mailalias sendmail rfc2047 rfc2045 ietf-drums mail-utils cursor-sensor
user-profile powerline powerline-separators powerline-themes server
default-profile default-ui paren man mm-util mail-prsvr recentf sort
dired-sort-menu dired dired-loaddefs desktop frameset avoid hl-line
default-faces default-keymap delsel cua-base default-run default-restart
default-modes default-platform default-unix default-flymake
default-flymake-go default-flymake-csharp default-flymake-ruby
default-flymake-js default-flymake-py default-flymake-java
default-flymake-shell flymake-proc flymake warnings default-run-assoc
run-assoc default-tempo default-tempo-rexx default-tempo-sh
default-tempo-pas default-tempo-js default-tempo-java default-tempo-perl
default-tempo-elisp default-tempo-c-cpp default-menu default-help
default-options default-tools default-search default-format default-view
aquamacs-cmm-menu default-edit default-file default-generic savehist
autorevert filenotify autoinsert default-functions elec-pair
default-autoload ox-man ox-odt rng-loc rng-uri rng-parse rng-match
rng-dt rng-util rng-pttrn nxml-parse nxml-ns nxml-enc xmltok nxml-util
ox-latex ox-icalendar ox-html table ox-ascii ox-publish ox org-element
avl-tree generator org org-macro org-footnote org-pcomplete pcomplete
org-list org-faces org-entities time-date org-version ob-emacs-lisp ob
ob-tangle org-src ob-ref ob-lob ob-table ob-keys ob-comint org-loaddefs
format-spec find-func cal-menu calendar cal-loaddefs ob-exp ob-core
org-compat ob-eval org-macs markdown-mode rx color thingatpt noutline
outline easy-mmode jison-mode bison-mode cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs flex-mode
derived aquamacs-tabbar cus-start cus-load aquamacs-tools tabbar
restore-last-frame-size org-bullets syslog-mode hide-lines web-mode
disp-table vimrc-mode neotree advice smooth-scroll aok cl
fill-column-indicator tempbuf auto-complete-config auto-complete edmacro
kmacro popup undo-tree diff multi-shell windata tree-mode tree-widget
wid-edit imenu imenu-tree tempo saveplace google-translate
google-translate-default-ui google-translate-core-ui ido
google-translate-core google-translate-tk url url-proxy url-privacy
url-expand url-methods url-history url-cookie url-domsuf url-util
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars mailcap json map seq byte-opt gv compile comint
ansi-color ring bytecomp byte-compile cconv cl-loaddefs cl-lib
eol-conversion easymenu default-path mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting xwidget-internal move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 290793 221183)
 (symbols 48 39498 7)
 (strings 32 97418 30674)
 (string-bytes 1 2962805)
 (vectors 16 38963)
 (vector-slots 8 759926 253378)
 (floats 8 375 1426)
 (intervals 56 627 476)
 (buffers 992 16))

bug#33602: 27.0.50; Compiling no file at

[Glenn Morris]

Markus FFM wrote:

> after each restart, a *Compile-log* buffer reports
> Compiling no file at <any date>

Not reproducible here with emacs -Q.

bug#33602: 27.0.50; Compiling no file at

[Colin Baxter]

Dear Markus
>>>>> Markus FFM <markusffm@fn.de> writes:

    > (is that a late April Fools' Day prank?)  after each restart, a
    > *Compile-log* buffer reports Compiling no file at <any date>

Yes, I get that too. It seems to arise because of some bye-compile
instructions in the emacs-init file. It doesn't arise using emacs -q, as
Glenn has pointed out.

---------- snip

    > seq byte-opt gv compile comint ansi-color ring bytecomp
    > byte-compile cconv cl-loaddefs cl-lib eol-conversion easymenu

Try turning off the effects of the above two lines.

Best wishes,


Colin Baxter
m43cap@yandex.com
---------------------------------------------------------------------
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
---------------------------------------------------------------------
The sole cause of all human misery is the inability of people to sit
quietly in their rooms.  Blaise Pascal, 1670
---------------------------------------------------------------------

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Markus.

In article <mailman.5104.1543865051.1284.bug-gnu-emacs@gnu.org> you wrote:

> (is that a late April Fools' Day prank?)
> after each restart, a *Compile-log* buffer reports
> Compiling no file at <any date>

This means that it was "compiling" an Emacs lisp form, and that rather
than being part of a source file, it was either an already evaluated
form, or was an Emacs-Lisp-Mode buffer.  I.e. it wasn't from a file ("no
file").

Maybe expressing the situation this way ("Compiling no file") is not
helpful.

By contrast, if you compiled a file with M-x byte-compile-file, the
message would say "Compiling bar/foo.el".

What is it that you're not happy with?  Is it the unhelpful message, or
the fact the the *Compile-log* buffer appears at all?

Could you please tell us whether your .emacs (or other initialisation
file) performs byte compilation, and if so, what commands it does this
with.

Thanks!

> In GNU Emacs 27.0.50 (build 20, x86_64-pc-linux-gnu, GTK+ Version 3.24.1)
>  of 2018-12-03 built on INDRA
> Repository revision: e5634aae531ce932ecb8d84243d690c7ca89bec3
> Repository branch: master
> Windowing system distributor 'Fedora Project', version 11.0.12003000
> System Description: Fedora 29 (Twenty Nine)

> Recent messages:
>>>>load time: Monday, December  3, 2018 20:15:49<<<
>>>>activated: themes<<<
> Desktop: 1 buffer restored.
> Loading /root/.emacs.d/framegeometry...done
> For information about GNU Emacs and the GNU system, type C-M-h C-a.
> Making completion list...
> smooth-scroll/.vscroll-aux: Beginning of buffer
> Making completion list...
> Quit
> Making completion list...

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Markus.

On Thu, Dec 06, 2018 at 22:58:33 +0100, markusffm@fn.de wrote:

> >Could you please tell us whether your .emacs (or other initialisation
> >file) performs byte compilation, and if so, what commands it does this
> >with.

> there is no byte compile during initialization. All the bytecode is 
> untouched for years; without problems until recently.

Yes.  I put some enhancements into the byte compiler's warning handler
very recently, and suspect that has triggered some existing problem, and
that is what you are seeing.

Having grepped Emacs's source, it seems like the byte compiler is the
only bit that writes "Compiling no file at ..." to the buffer
*Compile-Log*.  There are quite a few Emacs functions which call the
byte compiler, even though they are not byte compilations themselves.

Would you be prepared to help us with a bit of debugging?  What would be
useful is for you to "bisect" your .emacs file.

That is, comment out the second half of it (more or less), start Emacs
and note whether the silly warning happens.  If it does, comment out the
last three quarters (more or less) of .emacs, if it doesn't, comment
out the first quarter.  And so on.

This should quickly home in on the form in your .emacs which is
triggering the bug in Emacs.  Please tell us what this form is.  It
would help greatly in solving the problem

@Colin: any chance you could do the same, please.

> Regards M

By the way, would you please leave in the mailing list address as a Cc:,
so that everybody can see what's happening.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[martin rudalics]

 > Yes.  I put some enhancements into the byte compiler's warning handler
 > very recently, and suspect that has triggered some existing problem, and
 > that is what you are seeing.
 >
 > Having grepped Emacs's source, it seems like the byte compiler is the
 > only bit that writes "Compiling no file at ..." to the buffer
 > *Compile-Log*.  There are quite a few Emacs functions which call the
 > byte compiler, even though they are not byte compilations themselves.
 >
 > Would you be prepared to help us with a bit of debugging?  What would be
 > useful is for you to "bisect" your .emacs file.
 >
 > That is, comment out the second half of it (more or less), start Emacs
 > and note whether the silly warning happens.  If it does, comment out the
 > last three quarters (more or less) of .emacs, if it doesn't, comment
 > out the first quarter.  And so on.
 >
 > This should quickly home in on the form in your .emacs which is
 > triggering the bug in Emacs.  Please tell us what this form is.  It
 > would help greatly in solving the problem
 >
 > @Colin: any chance you could do the same, please.
 >
 >> Regards M
 >
 > By the way, would you please leave in the mailing list address as a Cc:,
 > so that everybody can see what's happening.  Thanks!

FWIW the problem is in package.el.  Have a look at the fix I just posted.

martin

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Martin.

On Fri, Dec 07, 2018 at 14:52:00 +0100, martin rudalics wrote:
>  > Yes.  I put some enhancements into the byte compiler's warning handler
>  > very recently, and suspect that has triggered some existing problem, and
>  > that is what you are seeing.

>  > Having grepped Emacs's source, it seems like the byte compiler is the
>  > only bit that writes "Compiling no file at ..." to the buffer
>  > *Compile-Log*.  There are quite a few Emacs functions which call the
>  > byte compiler, even though they are not byte compilations themselves.

>  > Would you be prepared to help us with a bit of debugging?  What would be
>  > useful is for you to "bisect" your .emacs file.

>  > That is, comment out the second half of it (more or less), start Emacs
>  > and note whether the silly warning happens.  If it does, comment out the
>  > last three quarters (more or less) of .emacs, if it doesn't, comment
>  > out the first quarter.  And so on.

>  > This should quickly home in on the form in your .emacs which is
>  > triggering the bug in Emacs.  Please tell us what this form is.  It
>  > would help greatly in solving the problem

>  > @Colin: any chance you could do the same, please.

>  >> Regards M

>  > By the way, would you please leave in the mailing list address as a Cc:,
>  > so that everybody can see what's happening.  Thanks!

> FWIW the problem is in package.el.  Have a look at the fix I just posted.

Could you perhaps be more explicit, please?  The problem with "Compiling
no file at ..." is one I can't even reproduce at the moment.

The patch you recently posted for package.el is something to do with
package.el being compiled or not being compiled.  What connection does
this have with the irritating appearance of the message in *Compile-Log*?

Thanks!

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[Colin Baxter]

>>>>> Alan Mackenzie <acm@muc.de> writes:

    > Hello, Markus.
    > On Thu, Dec 06, 2018 at 22:58:33 +0100, markusffm@fn.de wrote:

    >> >Could you please tell us whether your .emacs (or other
    >> initialisation >file) performs byte compilation, and if so, what
    >> commands it does this >with.

    >> there is no byte compile during initialization. All the bytecode
    >> is untouched for years; without problems until recently.

    > Yes.  I put some enhancements into the byte compiler's warning
    > handler very recently, and suspect that has triggered some
    > existing problem, and that is what you are seeing.

    > Having grepped Emacs's source, it seems like the byte compiler is
    > the only bit that writes "Compiling no file at ..." to the buffer
    > *Compile-Log*.  There are quite a few Emacs functions which call
    > the byte compiler, even though they are not byte compilations
    > themselves.

    > Would you be prepared to help us with a bit of debugging?  What
    > would be useful is for you to "bisect" your .emacs file.

    > That is, comment out the second half of it (more or less), start
    > Emacs and note whether the silly warning happens.  If it does,
    > comment out the last three quarters (more or less) of .emacs, if
    > it doesn't, comment out the first quarter.  And so on.

    > This should quickly home in on the form in your .emacs which is
    > triggering the bug in Emacs.  Please tell us what this form is.
    > It would help greatly in solving the problem

    > @Colin: any chance you could do the same, please.

Ok, I'll have a go. It may take a while because my ~/.emacs is years old
in the making and *very* unstructured.

    >> Regards M

    > By the way, would you please leave in the mailing list address as
    > a Cc:, so that everybody can see what's happening.  Thanks!

Sorry about that. I thought I was posting to the list but obviously not.

Best wishes,

bug#33602: 27.0.50; Compiling no file at

[martin rudalics]

 >> FWIW the problem is in package.el.  Have a look at the fix I just posted.
 >
 > Could you perhaps be more explicit, please?  The problem with "Compiling
 > no file at ..." is one I can't even reproduce at the moment.

Sorry, I had to leave and only wanted people to wait with bisecting
until Stefan resolved the current issue.  Beware also that I haven't
followed the threads with the issue discussed here so maybe I'm not
aware of all details.  IIUC all started with Markus reporting that

 > (is that a late April Fools' Day prank?)
 > after each restart, a *Compile-log* buffer reports
 > Compiling no file at <any date>

and one of the next days Angelo reported

 > Compiling no file at Thu Dec  6 09:46:33 2018

 From Angelo's init file I traced that message back to the presence of

(require 'package)

and removing that removed the message.  Then I looked into package.el
and found that code at its end:

       (insert "\f
;; Local\sVariables:
;; version-control: never
;;\sno-byte-compile: t
;; no-update-autoloads: t
;; End:
"))))

Since commenting out the

;;\sno-byte-compile: t

line again avoids the message I concluded that Stefan somehow got the
grep in makefile wrong which looks for

grep '^;.*no-byte-compile: t'

and apparently finds the one in that line.  So the connection you
asked for here

 > The patch you recently posted for package.el is something to do with
 > package.el being compiled or not being compiled.  What connection does
 > this have with the irritating appearance of the message in *Compile-Log*?

should be hopefully clear now.

My patch is just a workaround (which happens to work here) for people
to test. A clean fix could use 'concat' to produce that string (I have
no idea whether no-update-autoloads might be affected as well) like

       (insert (concat "\f\n"
                       ";; Local Variables:\n"
                       ";; version-control: never\n"
                       ";; no-byte-compile: t\n"
                       ";; no-update-autoloads: t\n"
                       ";; End:\n"))

so the ^;.* match is avoided by the spaces and the quotation mark.

martin

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Martin.

On Fri, Dec 07, 2018 at 18:49:54 +0100, martin rudalics wrote:
>  >> FWIW the problem is in package.el.  Have a look at the fix I just posted.

>  > Could you perhaps be more explicit, please?  The problem with "Compiling
>  > no file at ..." is one I can't even reproduce at the moment.

> Sorry, I had to leave and only wanted people to wait with bisecting
> until Stefan resolved the current issue.  Beware also that I haven't
> followed the threads with the issue discussed here so maybe I'm not
> aware of all details.  IIUC all started with Markus reporting that

>  > (is that a late April Fools' Day prank?)
>  > after each restart, a *Compile-log* buffer reports
>  > Compiling no file at <any date>

> and one of the next days Angelo reported

>  > Compiling no file at Thu Dec  6 09:46:33 2018

>  From Angelo's init file I traced that message back to the presence of

> (require 'package)

> and removing that removed the message.

When I insert that into my .emacs, regardless of whether near the
beginning or near the end, I don't get the *Compile-Log* buffer.

> Then I looked into package.el and found that code at its end:

>        (insert "\f
> ;; Local\sVariables:
> ;; version-control: never
> ;;\sno-byte-compile: t
> ;; no-update-autoloads: t
> ;; End:
> "))))

> Since commenting out the

> ;;\sno-byte-compile: t

> line again avoids the message I concluded that Stefan somehow got the
> grep in makefile wrong which looks for

> grep '^;.*no-byte-compile: t'

> and apparently finds the one in that line.  So the connection you
> asked for here

>  > The patch you recently posted for package.el is something to do with
>  > package.el being compiled or not being compiled.  What connection does
>  > this have with the irritating appearance of the message in *Compile-Log*?

> should be hopefully clear now.

Sorry, it's not at all clear.  I just don't see how a mix up in the
Local Variables section(s) can cause the appearance of *Compile-Log*
with its irritating message.  I can't reproduce the problem, either.

What is the causal connection between the Local Variables: mixup and the
appearnace of the *Compile-Log* buffer?

> My patch is just a workaround (which happens to work here) for people
> to test. A clean fix could use 'concat' to produce that string (I have
> no idea whether no-update-autoloads might be affected as well) like

>        (insert (concat "\f\n"
>                        ";; Local Variables:\n"
>                        ";; version-control: never\n"
>                        ";; no-byte-compile: t\n"
>                        ";; no-update-autoloads: t\n"
>                        ";; End:\n"))

> so the ^;.* match is avoided by the spaces and the quotation mark.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[martin rudalics]

 >>   From Angelo's init file I traced that message back to the presence of
 >
 >> (require 'package)
 >
 >> and removing that removed the message.
 >
 > When I insert that into my .emacs, regardless of whether near the
 > beginning or near the end, I don't get the *Compile-Log* buffer.

Did you remove any package.elc first?

martin

bug#33602: 27.0.50; Compiling no file at

[Eli Zaretskii]

> Date: Fri, 7 Dec 2018 18:11:12 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: Colin Baxter <m43cap@yandex.com>, "markusffm@fn.de" <markusffm@fn.de>,
> 	33602@debbugs.gnu.org
> 
> > and one of the next days Angelo reported
> 
> >  > Compiling no file at Thu Dec  6 09:46:33 2018
> 
> >  From Angelo's init file I traced that message back to the presence of
> 
> > (require 'package)
> 
> > and removing that removed the message.
> 
> When I insert that into my .emacs, regardless of whether near the
> beginning or near the end, I don't get the *Compile-Log* buffer.

Are you using the master branch?  Those problems are specific to the
master branch, AFAIU.

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Eli.

On Fri, Dec 07, 2018 at 20:43:35 +0200, Eli Zaretskii wrote:
> > Date: Fri, 7 Dec 2018 18:11:12 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: Colin Baxter <m43cap@yandex.com>, "markusffm@fn.de" <markusffm@fn.de>,
> > 	33602@debbugs.gnu.org

> > > and one of the next days Angelo reported

> > >  > Compiling no file at Thu Dec  6 09:46:33 2018

> > >  From Angelo's init file I traced that message back to the presence of

> > > (require 'package)

> > > and removing that removed the message.

> > When I insert that into my .emacs, regardless of whether near the
> > beginning or near the end, I don't get the *Compile-Log* buffer.

> Are you using the master branch?  Those problems are specific to the
> master branch, AFAIU.

I am, yes.  But I hadn't updated the particular version I was using for
quite some time.  I have updated it now.

Now I see the *Compile-Log* buffer with its irritating message regardless
of whether I have (require 'package) in my .emacs or not.  ;-(

At least I've got something to work on, now.  (That's assuming that
nobody else understands the bug, yet.)

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[Glenn Morris]

So much time is wasted on Emacs issues because people don't give minimal
clear examples, and we try to figure things out without insisting on one.
Anyway, here's mine:

emacs -Q -l seq

Now there is a Compile-Log buffer.

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Martin.

On Fri, Dec 07, 2018 at 19:42:42 +0100, martin rudalics wrote:
>  >>   From Angelo's init file I traced that message back to the presence of

>  >> (require 'package)

>  >> and removing that removed the message.

>  > When I insert that into my .emacs, regardless of whether near the
>  > beginning or near the end, I don't get the *Compile-Log* buffer.

> Did you remove any package.elc first?

I actually didn't have one, as it turns out.  But I pulled all recent
changes from Savannah and rebuilt.  Now I see the symptom, regardless of
whether I have (require 'package) in my .emacs or not.

I will now try to diagnose what is causing this.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 07 Dec 2018 14:01:46 -0500
> Cc: "markusffm@fn.de" <markusffm@fn.de>, 33602@debbugs.gnu.org,
> 	Colin Baxter <m43cap@yandex.com>
> 
> emacs -Q -l seq
> 
> Now there is a Compile-Log buffer.

Thanks, here's the backtrace for that:

  (and (get-buffer byte-compile-log-buffer) (equal byte-compile-current-file byte-compile-last-logged-file))
  (not (and (get-buffer byte-compile-log-buffer) (equal byte-compile-current-file byte-compile-last-logged-file)))
  (and (not (and (get-buffer byte-compile-log-buffer) (equal byte-compile-current-file byte-compile-last-logged-file))) (not noninteractive) (save-current-buffer (set-buffer (get-buffer-create byte-compile-log-buffer)) (goto-char (point-max)) (let* ((inhibit-read-only t) (dir (and (stringp byte-compile-current-file) (file-name-directory byte-compile-current-file))) (was-same (equal default-directory dir)) pt) (if dir (progn (if was-same nil (insert (format-message "Leaving directory `%s'\n" default-directory))))) (if (bolp) nil (insert "\n")) (setq pt (point-marker)) (if byte-compile-current-file (insert "\f\nCompiling " (if (stringp byte-compile-current-file) (concat "file " byte-compile-current-file) (concat "in buffer " (buffer-name byte-compile-current-file))) " at " (current-time-stri
 ng) "\n") (insert "\f\nCompiling no file at " (current-time-string) "\n")) (if dir (progn (setq default-directory dir) (if was-same nil (insert (format-message "Entering directory `%s'\n" default-directory))))) (setq byte-compile-last-logged-file byte-compile-current-file byte-compile-last-warned-form nil) (if (derived-mode-p 'compilation-mode) nil (emacs-lisp-compilation-mode)) (compilation-forget-errors) pt)))
  byte-compile-log-file()
  (or (byte-compile-log-file) 'byte-compile-warning-series)
  (let ((warning-series (or (byte-compile-log-file) 'byte-compile-warning-series))) (if byte-compile-debug (funcall --displaying-byte-compile-warnings-fn) (condition-case error-info (funcall --displaying-byte-compile-warnings-fn) (error (byte-compile-report-error error-info)))))
  (if (or (eq warning-series 'byte-compile-warning-series) warning-series-started) (let (tem) (setq tem (byte-compile-log-file)) (if warning-series-started nil (setq warning-series (or tem 'byte-compile-warning-series))) (if byte-compile-debug (funcall --displaying-byte-compile-warnings-fn) (condition-case error-info (funcall --displaying-byte-compile-warnings-fn) (error (byte-compile-report-error error-info))))) (let ((warning-series (or (byte-compile-log-file) 'byte-compile-warning-series))) (if byte-compile-debug (funcall --displaying-byte-compile-warnings-fn) (condition-case error-info (funcall --displaying-byte-compile-warnings-fn) (error (byte-compile-report-error error-info))))))
  (let* ((--displaying-byte-compile-warnings-fn #'(lambda nil (let ((byte-compile-macro-environment ...) (byte-compile--outbuffer nil) (overriding-plist-environment nil) (byte-compile-function-environment nil) (byte-compile-bound-variables nil) (byte-compile-lexical-variables nil) (byte-compile-const-variables nil) (byte-compile-free-references nil) (byte-compile-free-assignments nil) (byte-compile-verbose byte-compile-verbose) (byte-optimize byte-optimize) (byte-compile-dynamic byte-compile-dynamic) (byte-compile-dynamic-docstrings byte-compile-dynamic-docstrings) (byte-compile-warnings byte-compile-warnings)) (let* (... ... ...) (if macro ...) (cond ... ...))))) (warning-series-started (and (markerp warning-series) (eq (marker-buffer warning-series) (get-buffer byte-compile-log-buffer)))
 )) (byte-compile-find-cl-functions) (if (or (eq warning-series 'byte-compile-warning-series) warning-series-started) (let (tem) (setq tem (byte-compile-log-file)) (if warning-series-started nil (setq warning-series (or tem 'byte-compile-warning-series))) (if byte-compile-debug (funcall --displaying-byte-compile-warnings-fn) (condition-case error-info (funcall --displaying-byte-compile-warnings-fn) (error (byte-compile-report-error error-info))))) (let ((warning-series (or (byte-compile-log-file) 'byte-compile-warning-series))) (if byte-compile-debug (funcall --displaying-byte-compile-warnings-fn) (condition-case error-info (funcall --displaying-byte-compile-warnings-fn) (error (byte-compile-report-error error-info)))))))
  byte-compile((lambda (generic dispatches-left methods) (let ((method-cache (make-hash-table :test #'eql))) (lambda (arg0 arg &rest args) (let nil (apply (cl--generic-with-memoization (gethash ... method-cache) (cl--generic-cache-miss generic ... dispatches-left methods ...)) arg0 arg args))))))
  cl--generic-get-dispatcher((1 #s(cl--generic-generalizer :name cl--generic-typeof-generalizer :priority 10 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb95ff0>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb95fc0>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>))))
  cl--generic-make-next-function(#s(cl--generic :name \(setf\ seq-elt\) :dispatches ((2 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>))) (1 #s(cl--generic-generalizer :name cl--generic-typeof-generalizer :priority 10 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb95ff0>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb95fc0>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function 
 (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>))) (0 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>)))) :method-table (#s(cl--generic-method :specializers (t array t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (store sequence n) #<bytecode -0x1ffffffffe48d7c0>))) :options nil) ((2 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>))) (1 #s(cl--generic-generalizer :name cl--generic
 -typeof-generalizer :priority 10 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb95ff0>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb95fc0>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>))) (0 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>)))) (#s(cl--generic-method :specializers (t array t) :qualifiers nil :uses-cnm nil :
 function #f(compiled-function (store sequence n) #<bytecode -0x1ffffffffe48d7c0>))))
  cl--generic-make-function(#s(cl--generic :name \(setf\ seq-elt\) :dispatches ((2 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>))) (1 #s(cl--generic-generalizer :name cl--generic-typeof-generalizer :priority 10 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb95ff0>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb95fc0>)) #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag 
 &rest _) #<bytecode -0x1ffffffffeb99bf0>))) (0 #s(cl--generic-generalizer :name cl--generic-t-generalizer :priority 0 :tagcode-function #f(compiled-function (name &rest _) #<bytecode -0x1ffffffffeb99c30>) :specializers-function #f(compiled-function (tag &rest _) #<bytecode -0x1ffffffffeb99bf0>)))) :method-table (#s(cl--generic-method :specializers (t array t) :qualifiers nil :uses-cnm nil :function #f(compiled-function (store sequence n) #<bytecode -0x1ffffffffe48d7c0>))) :options nil))
  cl-generic-define-method(\(setf\ seq-elt\) nil (store (sequence array) n) nil #f(compiled-function (store sequence n) #<bytecode -0x1ffffffffe48d7c0>))
  byte-code("\300\301\302\303#\304\301\305\306#\210\307\310\311\310\312\313#\314#\210\315\310\313\312\313\316%\210\315\317\313\320\313\321%\210\315\317\313\322\313\323%\210\307\324\311\324\325..." [function-put seq-let lisp-indent-function 2 put edebug-form-spec (sexp form body) defalias seq-elt cl-generic-define (sequence n) nil "Return Nth element of SEQUENCE.\n\n(fn SEQUENCE N)" cl-generic-define-method #f(compiled-function (sequence n) #<bytecode -0x1ffffffffe54c358>) \(setf\ seq-elt\) (store (sequence array) n) #f(compiled-function (store sequence n) #<bytecode -0x1ffffffffe48d7c0>) (store (sequence cons) n) #f(compiled-function (store sequence n) #<bytecode -0x1ffffffffe480810>) seq-length (sequence) "Return the number of elements of SEQUENCE.\n\n(fn SE..." #f(compiled-function (sequ
 ence) #<bytecode -0x1ffffffffe4808d0>) seq-do #'sequence "Apply FUNCTION to each element of SEQUENCE, presum..." #f(compiled-function #'sequence #<bytecode -0x1ffffffffe47f980>) seq-each] 7)
  load("seq")

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Eli.

On Fri, Dec 07, 2018 at 21:17:50 +0200, Eli Zaretskii wrote:
> > From: Glenn Morris <rgm@gnu.org>
> > Date: Fri, 07 Dec 2018 14:01:46 -0500
> > Cc: "markusffm@fn.de" <markusffm@fn.de>, 33602@debbugs.gnu.org,
> > 	Colin Baxter <m43cap@yandex.com>

> > emacs -Q -l seq

Thanks, Glenn, that was inspired.

> > Now there is a Compile-Log buffer.

> Thanks, here's the backtrace for that:

You were ten minutes ahead of me.  :-)

[ snipped, for brevity. ]

Yes.  cl--generic-get-dispatcher calls byte-compile directly.  It calls
it on a generated lambda form.  Do we still need to do this nowadays?  I
thought the byte compiler had been enhanced to detect and compile such
forms automatically.

-- 
Alan Mackenzie (Nuremberg, Germany.

bug#33602: 27.0.50; Compiling no file at

[Eli Zaretskii]

> Date: Fri, 7 Dec 2018 19:27:07 +0000
> Cc: Glenn Morris <rgm@gnu.org>, markusffm@fn.de, 33602@debbugs.gnu.org,
>   m43cap@yandex.com
> From: Alan Mackenzie <acm@muc.de>
> 
> Yes.  cl--generic-get-dispatcher calls byte-compile directly.  It calls
> it on a generated lambda form.  Do we still need to do this nowadays?  I
> thought the byte compiler had been enhanced to detect and compile such
> forms automatically.

I'd ask a different question altogether: now that we know this comes
from loading generics, why is that entry in compilation log a problem?
Who cares what the byte compiler says as part of its normal operation,
and why should we consider that "a bug"?

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Eli.

On Fri, Dec 07, 2018 at 21:52:48 +0200, Eli Zaretskii wrote:
> > Date: Fri, 7 Dec 2018 19:27:07 +0000
> > Cc: Glenn Morris <rgm@gnu.org>, markusffm@fn.de, 33602@debbugs.gnu.org,
> >   m43cap@yandex.com
> > From: Alan Mackenzie <acm@muc.de>

> > Yes.  cl--generic-get-dispatcher calls byte-compile directly.  It calls
> > it on a generated lambda form.  Do we still need to do this nowadays?  I
> > thought the byte compiler had been enhanced to detect and compile such
> > forms automatically.

> I'd ask a different question altogether: now that we know this comes
> from loading generics, why is that entry in compilation log a problem?
> Who cares what the byte compiler says as part of its normal operation,
> and why should we consider that "a bug"?

I still think it's a problem.  It irritates people.

The actual wording of the message "Compiling no file at <time>" is
unclear.  Certainly to a German speaker, it reads identically to "Not
compiling a file at <time>" - why are we reporting on what we're not
doing?  What's really meant is "compiling something, but it's not in a
file".

The message is not in response to a user action - it's Emacs's internal
processing.  The user requested a file to be loaded, not compiled.

The message is content free.  It fails to identify what's being
compiled.  (This could be fixed easily in bytecomp.el.)

Guessing from Markus (the OP)'s post, it seems that the *Compile-Log*
buffer is the current buffer at start up time.  Who needs that?

So, yes, I think it's a bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[Eli Zaretskii]

> Date: Fri, 7 Dec 2018 20:06:59 +0000
> Cc: rgm@gnu.org, markusffm@fn.de, 33602@debbugs.gnu.org, m43cap@yandex.com
> From: Alan Mackenzie <acm@muc.de>
> 
> > I'd ask a different question altogether: now that we know this comes
> > from loading generics, why is that entry in compilation log a problem?
> > Who cares what the byte compiler says as part of its normal operation,
> > and why should we consider that "a bug"?
> 
> I still think it's a problem.  It irritates people.

They are free not to look ;-)

> The actual wording of the message "Compiling no file at <time>" is
> unclear.

If we want to change the text, it's fine.  But removing the log
altogether sounds like too much to me.

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Eli.

On Sat, Dec 08, 2018 at 12:48:12 +0200, Eli Zaretskii wrote:
> > Date: Fri, 7 Dec 2018 20:06:59 +0000
> > Cc: rgm@gnu.org, markusffm@fn.de, 33602@debbugs.gnu.org, m43cap@yandex.com
> > From: Alan Mackenzie <acm@muc.de>

> > > I'd ask a different question altogether: now that we know this comes
> > > from loading generics, why is that entry in compilation log a problem?
> > > Who cares what the byte compiler says as part of its normal operation,
> > > and why should we consider that "a bug"?

> > I still think it's a problem.  It irritates people.

> They are free not to look ;-)

No comment.  ;-)

> > The actual wording of the message "Compiling no file at <time>" is
> > unclear.

> If we want to change the text, it's fine.  But removing the log
> altogether sounds like too much to me.

Why?  The log doesn't appear in Emacs-26.  It does appear in recent
versions of master.  The creation of this buffer is an unintended
consequence of the amendments I made to the byte compiler's warning
message mechanism around a week and a half ago.

In a call of byte-compile, both byte-compile-current-file and
byte-compile-last-logged-file tend to be nil.

Whereas the condition at the top of byte-compile-log-file used to be

    (not (equal byte-compile-current-file byte-compile-last-logged-file))

, now it additionally checks

    (get-buffer byte-compile-log-buffer)

, and "re"creates that buffer if it doesn't exist.

So previously, *Compile-Log* didn't get created.  Now it does.  I think
I should revert that part of the change.  What do you say?

Changing the wording is a separate issue, but I think it should also be
done.  I would suggest instead of "Compiling no file at <time>" we say
"Compiling, not from a file, at <time>".

In other words:


diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index d6986cb786..58c55f7a2e 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -1179,9 +1179,7 @@ byte-compile-warning-series
 ;; Return the position of the start of the page in the log buffer.
 ;; But do nothing in batch mode.
 (defun byte-compile-log-file ()
-  (and (not
-        (and (get-buffer byte-compile-log-buffer)
-             (equal byte-compile-current-file byte-compile-last-logged-file)))
+  (and (not (equal byte-compile-current-file byte-compile-last-logged-file))
        (not noninteractive)
        (with-current-buffer (get-buffer-create byte-compile-log-buffer)
 	 (goto-char (point-max))
@@ -1204,7 +1202,7 @@ byte-compile-log-file
 			 (concat "in buffer "
                                  (buffer-name byte-compile-current-file)))
 		       " at " (current-time-string) "\n")
-	     (insert "\f\nCompiling no file at " (current-time-string) "\n"))
+	     (insert "\f\nCompiling, not from a file, at " (current-time-string) "\n"))
 	   (when dir
 	     (setq default-directory dir)
 	     (unless was-same

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[Eli Zaretskii]

> Date: Sat, 8 Dec 2018 20:07:05 +0000
> Cc: rgm@gnu.org, markusffm@fn.de, 33602@debbugs.gnu.org, m43cap@yandex.com
> From: Alan Mackenzie <acm@muc.de>
> 
> > If we want to change the text, it's fine.  But removing the log
> > altogether sounds like too much to me.
> 
> Why?  The log doesn't appear in Emacs-26.  It does appear in recent
> versions of master.  The creation of this buffer is an unintended
> consequence of the amendments I made to the byte compiler's warning
> message mechanism around a week and a half ago.
> 
> In a call of byte-compile, both byte-compile-current-file and
> byte-compile-last-logged-file tend to be nil.
> 
> Whereas the condition at the top of byte-compile-log-file used to be
> 
>     (not (equal byte-compile-current-file byte-compile-last-logged-file))
> 
> , now it additionally checks
> 
>     (get-buffer byte-compile-log-buffer)
> 
> , and "re"creates that buffer if it doesn't exist.
> 
> So previously, *Compile-Log* didn't get created.  Now it does.  I think
> I should revert that part of the change.  What do you say?

No objections here.

> Changing the wording is a separate issue, but I think it should also be
> done.  I would suggest instead of "Compiling no file at <time>" we say
> "Compiling, not from a file, at <time>".

That still sounds strange to me.  How about

  Compiling (no file name) at TIME

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

Hello, Eli.

On Sat, Dec 08, 2018 at 22:36:50 +0200, Eli Zaretskii wrote:
> > Date: Sat, 8 Dec 2018 20:07:05 +0000
> > Cc: rgm@gnu.org, markusffm@fn.de, 33602@debbugs.gnu.org, m43cap@yandex.com
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> > So previously, *Compile-Log* didn't get created.  Now it does.  I think
> > I should revert that part of the change.  What do you say?

> No objections here.

Thanks.  I'll make that change.

> > Changing the wording is a separate issue, but I think it should also be
> > done.  I would suggest instead of "Compiling no file at <time>" we say
> > "Compiling, not from a file, at <time>".

> That still sounds strange to me.  How about

>   Compiling (no file name) at TIME

That doesn't sound quite right, either.  It's not the name of the file
that we're missing, it's the file itself.  How about something like:

    Compiling internal form(s) at TIME

?  It's more positive, saying what we're doing rather than not doing.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#33602: 27.0.50; Compiling no file at

[Eli Zaretskii]

> Date: Sun, 9 Dec 2018 11:30:01 +0000
> Cc: rgm@gnu.org, markusffm@fn.de, 33602@debbugs.gnu.org, m43cap@yandex.com
> From: Alan Mackenzie <acm@muc.de>
> 
>     Compiling internal form(s) at TIME

SGTM, thanks.

bug#33602: 27.0.50; Compiling no file at

[Alan Mackenzie]

On Sun, Dec 09, 2018 at 14:43:05 +0200, Eli Zaretskii wrote:
> > Date: Sun, 9 Dec 2018 11:30:01 +0000
> > Cc: rgm@gnu.org, markusffm@fn.de, 33602@debbugs.gnu.org, m43cap@yandex.com
> > From: Alan Mackenzie <acm@muc.de>

> >     Compiling internal form(s) at TIME

> SGTM, thanks.

OK, I've committed the patch, and I'm closing the bug.

@Markus: the buffer *Compile-Log* should now no longer get created at
Emacs startup.

-- 
Alan Mackenzie (Nuremberg, Germany).