bug#64143: 29.0.60; find-function-search-for-symbol truncates library path

[Troy Brown <brownts@troybrown.dev>]

Eli Zaretskii <eliz@gnu.org> writes:

> What do you mean by "truncates the library path"?  Do you mean
> truncation of the file name 'emacs.el' to yield just 'emacs'? or do
> you mean something else?  (To avoid confusion, please don't use "path"
> to refer to file names, only to refer to lists of directories in the
> style of PATH or load-path.)

I was referring specifically to the LIBRARY parameter passed into
find-function-search-for-symbol.  In this scenario, I'd expect it to be
passed to find-library-name unaltered.  In other words, the value of the
LIBRARY parameter passed in is:
  "/home/troy/.emacs.elpa/elpa/company-20230416.2034/company.el"

However, the value passed on to find-library-name is:
  "/home/troy/.emacs"

This is being altered due to the fact that it contains a ".emacs.el"
substring within it (i.e., "/home/troy/<.emacs.el>pa").

> This says it cannot find ".emacs", not "emacs".  So is your init file
> called ".emacs.el" or (as you mentioned above) "emacs.el"?

The problem has nothing to do with my init file (and manifests
regardless of init file name), only whether the path supplied by
--init-directory contains an ".emacs.el" substring in it (which
"~/.emacs.elpa" clearly does).

Here is a more precise way to reproduce this using "emacs -Q".  I was
previously trying to provide a real-world example of how I was seeing
this behavior, but maybe it added confusion.

If we toggle "debug-on-error" and then evaluate each expression below in
turn, we can examine the value that find-function-search-for-symbol
passes to find-library-name (as this assumes a bogus username "someuser"
and thus an invalid path to trigger the error).  In the first case
(simulating using --init-directory=/home/someuser/.emacs.d), the value
is as expected (the value passed as the LIBRARY parameter to
find-function-search-for-symbol).  In the second case (simulating using
--init-directory=/home/someuser/.emacs.elpa), we see that the value
passed to find-library-name is no longer the same as the value passed as
the LIBRARY parameter to find-function-search-for-symbol, but was
truncated instead.

(find-function-search-for-symbol 'company-mode nil
"/home/someuser/.emacs.d/elpa/company-20230416.2034/company.el")
(find-function-search-for-symbol 'company-mode nil
"/home/someuser/.emacs.elpa/elpa/company-20230416.2034/company.el")


Debugger entered--Lisp error: (file-error "Can't find library"
"/home/someuser/.emacs.d/elpa/company-20230416.2034/company.el")
  find-library-name("/home/someuser/.emacs.d/elpa/company-20230416.2034/company.el")
  find-function-search-for-symbol(company-mode nil
"/home/someuser/.emacs.d/elpa/company-20230416.2034/company.el")
  (progn (find-function-search-for-symbol 'company-mode nil
"/home/someuser/.emacs.d/elpa/company-20230416.2034/company.el"))
  eval((progn (find-function-search-for-symbol 'company-mode nil
"/home/someuser/.emacs.d/elpa/company-20230416.2034/company.el")) t)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

Debugger entered--Lisp error: (file-error "Can't find library"
"/home/someuser/.emacs")
  find-library-name("/home/someuser/.emacs")
  find-function-search-for-symbol(company-mode nil
"/home/someuser/.emacs.elpa/elpa/company-20230416.2034/company.el")
  (progn (find-function-search-for-symbol 'company-mode nil
"/home/someuser/.emacs.elpa/elpa/company-20230416.2034/company.el"))
  eval((progn (find-function-search-for-symbol 'company-mode nil
"/home/someuser/.emacs.elpa/elpa/company-20230416.2034/company.el"))
t)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

> Does the patch below fix this problem?
>

Indeed, it does.

> Also, I see that you have some advice installed for
> find-function-search-for-symbol.  Would you please verify that
> removing that advice still produces the problem in Emacs 29?
>

See above where I provided a way to reproduce this using just "emacs -Q".