bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Steps to reproduce:

emacs -Q
C-u C-h d window RET

Actual result:

An error is shown:

apropos-documentation-check-elc-file: Opening input file: No such file
or directory, <Path_to_emacs>/simple.elc

Backtrace:

Debugger entered--Lisp error: (file-missing "Opening input file" "No such file or directory" "<Path_to_emacs>/simple.elc")
  insert-file-contents("simple.elc")
  apropos-documentation-check-elc-file("simple.elc")
  apropos-documentation-internal(("simple.elc" . 202399))
  #f(compiled-function (symbol) #<bytecode -0x13cfcf14a608b59f>)(kill-current-buffer)
  mapatoms(#f(compiled-function (symbol) #<bytecode -0x13cfcf14a608b59f>))
  apropos-documentation(("window") (4))
  funcall-interactively(apropos-documentation ("window") (4))
  call-interactively(apropos-documentation nil nil)
  command-execute(apropos-documentation)

Expected result:

Emacs shows symbols that contain "window" in its documentation, or a
specific error that says that no results are found.


In GNU Emacs 29.0.50 (build 60, aarch64-apple-darwin21.4.0, NS appkit-2113.40 Version 12.3.1 (Build 21E258))
 of 2022-05-17 built on Daniels-MacBook-Pro.local
Repository revision: 092aea9a27831a378ff8d1ab94a096675fe92343
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.3.1

Configured using:
 'configure --with-webp=no
 CPPFLAGS=-I/opt/homebrew/opt/openjdk@11/include'

Configured features:
ACL DBUS GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER
PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS XIM ZLIB

Important settings:
  value of $LC_CTYPE: UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
apropos iso-transl tooltip eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice simple 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 emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
kqueue cocoa ns lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 43105 7568)
 (symbols 48 5739 1)
 (strings 32 15418 1136)
 (string-bytes 1 498864)
 (vectors 16 11176)
 (vector-slots 8 159643 10882)
 (floats 8 20 32)
 (intervals 56 194 0)
 (buffers 992 11))

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Lars Ingebrigtsen]

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:
> emacs -Q
> C-u C-h d window RET
>
> Actual result:
>
> An error is shown:
>
> apropos-documentation-check-elc-file: Opening input file: No such file
> or directory, <Path_to_emacs>/simple.elc

I see the same if I start Emacs now, and the root cause is

(apropos-safe-documentation 'kill-current-buffer)

which again is because of this

(aref (symbol-function 'kill-current-buffer) 4)
=> ("simple.elc" . 202401)

Now, in my Emacs that's been running for a few hours, I instead get:

(aref (symbol-function 'kill-current-buffer) 4)
=> ("/home/larsi/src/emacs/trunk/lisp/simple.elc" . 202401)

And everything works.

I've tried to bisect this problem, but it's odd -- I can reproduce the
problem from "emacs -Q", but then if ... some things I don't quite
understand are done, then the problem goes away.

In any case, the simple.elc file contains:

(defalias 'kill-current-buffer ... (#$ . 202401) nil])

And #$ has apparently expanded to the unqualified version usually?

I think Stefan changed the format of byte compiled functions a while
ago?  Or do I misremember?  Anyway, added to the CCs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2022-05-18 01:00:07] wrote:

> Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>> emacs -Q
>> C-u C-h d window RET
>>
>> Actual result:
>>
>> An error is shown:
>>
>> apropos-documentation-check-elc-file: Opening input file: No such file
>> or directory, <Path_to_emacs>/simple.elc
>
> I see the same if I start Emacs now, and the root cause is
>
> (apropos-safe-documentation 'kill-current-buffer)
>
> which again is because of this
>
> (aref (symbol-function 'kill-current-buffer) 4)
> => ("simple.elc" . 202401)

What is the value of `lisp-directory` when you get that error?
What is the actual "<Path_to_emacs>" printed above?
Where should Emacs find the `simple.elc` file instead?

> Now, in my Emacs that's been running for a few hours, I instead get:
>
> (aref (symbol-function 'kill-current-buffer) 4)
> => ("/home/larsi/src/emacs/trunk/lisp/simple.elc" . 202401)

I suspect that this is because the `simple.elc` was reloaded for some
reason, which happens to hide the problem.

> I think Stefan changed the format of byte compiled functions a while
> ago?  Or do I misremember?  Anyway, added to the CCs.

Not really, no, but the docstrings of preloaded packages (like
`simple.el`) used to be (stored in and) fetched from `etc/DOC` and is
now fetched from the elc files instead.

The relevant change (and hence likely culprit here) is
59732a83c8875c8986d2221600d559a24d8309cc


        Stefan

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> What is the value of `lisp-directory` when you get that error?
> What is the actual "<Path_to_emacs>" printed above?
> Where should Emacs find the `simple.elc` file instead?

lisp-directory
=> "/home/larsi/src/emacs/trunk/lisp/"

<Path_to_emacs> up there is probably a misnomer -- it's just the current
directory.

>> Now, in my Emacs that's been running for a few hours, I instead get:
>>
>> (aref (symbol-function 'kill-current-buffer) 4)
>> => ("/home/larsi/src/emacs/trunk/lisp/simple.elc" . 202401)
>
> I suspect that this is because the `simple.elc` was reloaded for some
> reason, which happens to hide the problem.

Right.  Then perhaps the error is just in:

(apropos-documentation-check-elc-file "simple.elc")

It assumes a full file name, and doesn't look into the load path, which
it could trivially do.

But before I fix that -- is (aref (symbol-function 'kill-current-buffer)
4) supposed to be the full file name or just the leaf name?  I imagined
that #$ was supposed to expand to the full file name...  The manual just
says

‘#$’
     The current file name in byte-compiled files (*note Docs and
     Compilation::).  This is not meant to be used in Emacs Lisp source
     files.

which isn't very precise.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (apropos-documentation-check-elc-file "simple.elc")
>
> It assumes a full file name, and doesn't look into the load path, which
> it could trivially do.

I did that now, anyway, because it wasn't a very resilient function --
if .elc files had been deleted after starting Emacs, out would bug out
on that, too.

So the original reported bug should now be fixed in Emacs 29, but I
guess the question remains open whether #$ is working as designed here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> So the original reported bug should now be fixed in Emacs 29, but I
> guess the question remains open whether #$ is working as designed here?

I can confirm that the problem is fixed.  Thanks.

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Right.  Then perhaps the error is just in:
>
> (apropos-documentation-check-elc-file "simple.elc")
>
> It assumes a full file name, and doesn't look into the load path, which
> it could trivially do.

Looking up the `load-path` should be of last resort because it's not
reliable (e.g. when you have foo/bar/comp.elc it's not clear if it's
emacs-lisp/comp.elc or semantic/wisent/comp.elc).

> But before I fix that -- is (aref (symbol-function 'kill-current-buffer)
> 4) supposed to be the full file name or just the leaf name?

The file name should be absolute for all files except the preloaded
ones, and those should be relative to `lisp-directory` (because the
preloaded files are loaded before we know where the Lisp files will be
available at run-time).


        Stefan

bug#55492: 29.0.50; apropos-documentation with universal argument shows an error

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Looking up the `load-path` should be of last resort because it's not
> reliable (e.g. when you have foo/bar/comp.elc it's not clear if it's
> emacs-lisp/comp.elc or semantic/wisent/comp.elc).

[...]

> The file name should be absolute for all files except the preloaded
> ones, and those should be relative to `lisp-directory` (because the
> preloaded files are loaded before we know where the Lisp files will be
> available at run-time).

Ah, right.  I'll adjust the patch to expand to lisp-directory instead
(although it probably doesn't make any practical difference since this
is only about built-in files indeed).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no