"transient-define-suffix" autoload error ?

"transient-define-suffix" autoload error ?

[David Masterson]

I think the 'apt update' on Debian messed up the startup of Emacs 28.2,
but I'm not sure.  I'm getting an autoload error for
transient-define-suffix probably in the beginning of site startup, but I
can't figure how to find it.  My *Messages* file looks like this:

================
Error loading autoloads: (void-function transient-define-suffix)
Loading /etc/emacs/site-start.d/00debian.el (source)...done
Loading /etc/emacs/site-start.d/50autoconf.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...
Loading debian-ispell (native compiled elisp)...
Loading /var/cache/dictionaries-common/emacsen-ispell-default.el (source)...done
Loading debian-ispell (native compiled elisp)...done
Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...done
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50emacs-intl-fonts.el (source)...done
Loading /etc/emacs/site-start.d/50texlive-lang-english.el (source)...done
Loading /home/dsmasterson/.emacs.d/elpa/hyperbole-9.0.1/hyperbole-autoloads.el (source)...done
Loading hypb-ert (native compiled elisp)...done
Loading hib-social (native compiled elisp)...done
Loading hsys-www (native compiled elisp)...done
Loading hib-debbugs (native compiled elisp)...done
Loading hib-kbd (native compiled elisp)...done
Loading klink (native compiled elisp)...done
org-super-agenda-mode enabled.
Loading desktop (native compiled elisp)...done
Loading saveplace (native compiled elisp)...done
Initializing Hyperbole...done
For information about GNU Emacs and the GNU system, type C-h C-a.
================

Any pointers?
-- 
David Masterson

Re: "transient-define-suffix" autoload error ?

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Error loading autoloads: (void-function transient-define-suffix)

This error indicates "the" file was miscompiled because it uses
`transient-define-suffix` without making sure that macro is actually
defined (i.e. without `require`ing `transient`).

How to fix it depends on what "the" file is, and why
`transient-define-suffix` is there.


        Stefan

Re: "transient-define-suffix" autoload error ?

[David Masterson]

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>> Error loading autoloads: (void-function transient-define-suffix)
>
> This error indicates "the" file was miscompiled because it uses
> `transient-define-suffix` without making sure that macro is actually
> defined (i.e. without `require`ing `transient`).
>
> How to fix it depends on what "the" file is, and why
> `transient-define-suffix` is there.

That is my problem!  How do you find the file that is causing the error?
Based on where the error occurs in *Messages* and that it also prints to
standard error(?) as Emacs is starting, I would guess that the error is
occuring site-lisp or site-start.  A "--debug-init" doesn't give me
anything because Emacs hasn't gotten to the init file yet (CMIIAW).
Therefore, I guess it is not in any of my ,emacs.d/elpa packages.

I recognize what the problem is -- I'm just not sure how to find where
it is happening.

-- 
David Masterson

Re: "transient-define-suffix" autoload error ?

[Stefan Monnier]

> That is my problem!  How do you find the file that is causing the error?
> Based on where the error occurs in *Messages* and that it also prints to
> standard error(?) as Emacs is starting, I would guess that the error is
> occuring site-lisp or site-start.  A "--debug-init" doesn't give me
> anything because Emacs hasn't gotten to the init file yet (CMIIAW).
> Therefore, I guess it is not in any of my ,emacs.d/elpa packages.

Ah, right.  I think `--debug-init` *should* help (tho apparently it
doesn't, maybe that deserves its own bug-report), but otherwise you have
to resort to simulating the init by hand.  I.e. start with

    emacs -Q --eval '(setq debug-on-error t)'

and then try and manually load the site-init files.
But there's a chance the problem won't trigger in that case because of
some detail of when&how the files get loaded.


        Stefan

Re: "transient-define-suffix" autoload error ?

[David Masterson]

David Masterson <dsmasterson@gmail.com> writes:

> Stefan Monnier via Users list for the GNU Emacs text editor
> <help-gnu-emacs@gnu.org> writes:
>
>>> Error loading autoloads: (void-function transient-define-suffix)
>>
>> This error indicates "the" file was miscompiled because it uses
>> `transient-define-suffix` without making sure that macro is actually
>> defined (i.e. without `require`ing `transient`).
>>
>> How to fix it depends on what "the" file is, and why
>> `transient-define-suffix` is there.
>
> That is my problem!  How do you find the file that is causing the error?
> Based on where the error occurs in *Messages* and that it also prints to
> standard error(?) as Emacs is starting, I would guess that the error is
> occuring site-lisp or site-start.  A "--debug-init" doesn't give me
> anything because Emacs hasn't gotten to the init file yet (CMIIAW).
> Therefore, I guess it is not in any of my ,emacs.d/elpa packages.
>
> I recognize what the problem is -- I'm just not sure how to find where
> it is happening.

Followup:

A '--no-init-file' does make the error go away.  That suggests that it is
a problem with my packages.  The only packages that I am using that use
transient (AFAICT) is forge and magit.  Debugging them is going to be
difficult -- they looked good on requires in my first look.

I use-package to load almost all of my interesting package, so I tried
to ':disabled' these two as a first test.  The error still comes up.
I'm not sure how native compilation works internally, so I have some
questions:

1. When are the native packages loaded in the startup sequence?
2. Does disabling a package via use-package prevent the native code from
loading as well?
3. Is there a way to tell Emacs 28.2 to ignore the native code?
4. Does the natve compiler clean up old code from the cache?
5. Could my error be happening in the native code?

-- 
David Masterson

Re: "transient-define-suffix" autoload error ?

[Stefan Monnier]

> A '--no-init-file' does make the error go away.  That suggests that it is
> a problem with my packages.  The only packages that I am using that use
> transient (AFAICT) is forge and magit.  Debugging them is going to be
> difficult -- they looked good on requires in my first look.

Ah, then if `--debug-init` does not help, maybe you should

    emacs -Q --eval '(setq debug-on-error t debug-on-signal t) \
             -l ~/.emacs.d/init.el

which may give you a more interesting backtrace (but beware:
`debug-on-signal` will also give you false positives about errors which
aren't ones).

> I use-package to load almost all of my interesting package, so I tried
> to ':disabled' these two as a first test.  The error still comes up.

Maybe the problem is in `~/.emacs.d/package-quickstart.el(c)`?

> 1. When are the native packages loaded in the startup sequence?
> 2. Does disabling a package via use-package prevent the native code from
> loading as well?
> 3. Is there a way to tell Emacs 28.2 to ignore the native code?
> 4. Does the natve compiler clean up old code from the cache?
> 5. Could my error be happening in the native code?

I don't see any indication in what you sent that the problem is linked
to native compilation.  Of course, maybe it is, but my crystal ball is
screaming "look elsewhere".


        Stefan

Re: "transient-define-suffix" autoload error ?

[David Masterson]

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

>> A '--no-init-file' does make the error go away.  That suggests that it is
>> a problem with my packages.  The only packages that I am using that use
>> transient (AFAICT) is forge and magit.  Debugging them is going to be
>> difficult -- they looked good on requires in my first look.
>
> Ah, then if `--debug-init` does not help, maybe you should
>
>     emacs -Q --eval '(setq debug-on-error t debug-on-signal t) \
>              -l ~/.emacs.d/init.el

I'm old school -- ~/.emacs -- but I get the idea. ;-)

> which may give you a more interesting backtrace (but beware:
> `debug-on-signal` will also give you false positives about errors which
> aren't ones).

With debug-on-signal, I get:

Debugger entered--Lisp error: (void-variable kmacro-call-mouse-event)

Without debug-on-signal, I get:

Debugger entered--Lisp error: (file-missing "Cannot open load file"
  "No such file or directory" "use-package")
  require(use-package)

>> I use-package to load almost all of my interesting package, so I tried
>> to ':disabled' these two as a first test.  The error still comes up.
>
> Maybe the problem is in `~/.emacs.d/package-quickstart.el(c)`?

I don't have that file.

>> 1. When are the native packages loaded in the startup sequence?
>> 2. Does disabling a package via use-package prevent the native code from
>> loading as well?
>> 3. Is there a way to tell Emacs 28.2 to ignore the native code?
>> 4. Does the natve compiler clean up old code from the cache?
>> 5. Could my error be happening in the native code?
>
> I don't see any indication in what you sent that the problem is linked
> to native compilation.  Of course, maybe it is, but my crystal ball is
> screaming "look elsewhere".

Your crystal ball is much more advanced than mine when it comes to
Emacs, so I accept that.  However, I think my questions above should be
answered in the Emacs manuals somewhere to not make native compilation
opaque.

I don't trust ":disabled" in use-package.  I'm going to try commenting
out forge and magit.  I might also try safely removing them from
~/.emacs.d.

-- 
David Masterson

Re: "transient-define-suffix" autoload error ?

[Stefan Monnier via Users list for the GNU Emacs text editor]

> Without debug-on-signal, I get:
>
> Debugger entered--Lisp error: (file-missing "Cannot open load file"
>   "No such file or directory" "use-package")
>   require(use-package)

That is weird.  Clearly, this is not the real problem, but you may have
to fix this one before you can go back to investigate the real one.

> Your crystal ball is much more advanced than mine when it comes to
> Emacs, so I accept that.  However, I think my questions above should be
> answered in the Emacs manuals somewhere to not make native compilation
> opaque.

`.eln` files are indexed by the SHA of the corresponding `.elc`, so if
there's no `.elc` of if it has changed, you should never get some left
over `.eln` file instead.


        Stefan

Re: "transient-define-suffix" autoload error ?

[David Masterson]

David Masterson <dsmasterson@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> A '--no-init-file' does make the error go away.  That suggests that it is
>>> a problem with my packages.  The only packages that I am using that use
>>> transient (AFAICT) is forge and magit.  Debugging them is going to be
>>> difficult -- they looked good on requires in my first look.
>>
>> Ah, then if `--debug-init` does not help, maybe you should
>>
>>     emacs -Q --eval '(setq debug-on-error t debug-on-signal t) \
>>              -l ~/.emacs.d/init.el
>
> I'm old school -- ~/.emacs -- but I get the idea. ;-)
>
>> which may give you a more interesting backtrace (but beware:
>> `debug-on-signal` will also give you false positives about errors which
>> aren't ones).
>
> With debug-on-signal, I get:
>
> Debugger entered--Lisp error: (void-variable kmacro-call-mouse-event)
>
> Without debug-on-signal, I get:
>
> Debugger entered--Lisp error: (file-missing "Cannot open load file"
>   "No such file or directory" "use-package")
>   require(use-package)
>
>>> I use-package to load almost all of my interesting package, so I tried
>>> to ':disabled' these two as a first test.  The error still comes up.
>>
>> Maybe the problem is in `~/.emacs.d/package-quickstart.el(c)`?
>
> I don't have that file.
>
>>> 1. When are the native packages loaded in the startup sequence?
>>> 2. Does disabling a package via use-package prevent the native code from
>>> loading as well?
>>> 3. Is there a way to tell Emacs 28.2 to ignore the native code?
>>> 4. Does the natve compiler clean up old code from the cache?
>>> 5. Could my error be happening in the native code?
>>
>> I don't see any indication in what you sent that the problem is linked
>> to native compilation.  Of course, maybe it is, but my crystal ball is
>> screaming "look elsewhere".
>
> Your crystal ball is much more advanced than mine when it comes to
> Emacs, so I accept that.  However, I think my questions above should be
> answered in the Emacs manuals somewhere to not make native compilation
> opaque.
>
> I don't trust ":disabled" in use-package.  I'm going to try commenting
> out forge and magit.  I might also try safely removing them from
> ~/.emacs.d.

I think I found it -- it's in forge-autoloads.el.  I wondered about your
suggested startup with debug-on-error and noticed that the packages in
~/.emacs,d/elpa were not added to the load-path suggesting
package-initialize had not run.  When I ran that, the debugger found the
file.  Now, I have to walk through the code to see how it was supposed
to require 'transient and raise a bug.

Thanks.

-- 
David Masterson

Re: "transient-define-suffix" autoload error ?

[David Masterson]

Stefan Monnier via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

>> Without debug-on-signal, I get:
>>
>> Debugger entered--Lisp error: (file-missing "Cannot open load file"
>>   "No such file or directory" "use-package")
>>   require(use-package)
>
> That is weird.  Clearly, this is not the real problem, but you may have
> to fix this one before you can go back to investigate the real one.

What is it that initializes the load-path to include all the packages in
~/.emacs.d/elpa -- package-initialize? I think there is something wrong
with this part of my .emacs with respect to emacs -Q:

================
(require 'package)
(setq package-archives '(
			 ("org" . "https://orgmode.org/elpa/")
			 ("elpa" . "https://elpa.gnu.org/packages/")
			 ("melpa" . "https://melpa.org/packages/")
			 ))
(setq package-archive-priorities '(
				   ("org" . 10)
				   ("elpa" . 20)
				   ("melpa" . 1)
				   ))
(unless (fboundp 'package-activate-all) (package-initialize))

(unless (package-installed-p 'use-package)
  (package-install 'use-package))
(eval-when-compile
  (require 'use-package)
  (require 'bind-key)
  )
================

>> Your crystal ball is much more advanced than mine when it comes to
>> Emacs, so I accept that.  However, I think my questions above should be
>> answered in the Emacs manuals somewhere to not make native compilation
>> opaque.
>
> `.eln` files are indexed by the SHA of the corresponding `.elc`, so if
> there's no `.elc` of if it has changed, you should never get some left
> over `.eln` file instead.

I noticed a few packages had been updated and both the old and new
version had eln files in the cache.

-- 
David Masterson

Re: "transient-define-suffix" autoload error ?

[Stefan Monnier]

> What is it that initializes the load-path to include all the packages in
> ~/.emacs.d/elpa -- package-initialize?

Nowadays it's `package-activate-all`, which is normally called by Emacs
between `early-init.el` and `init.el` (i.e. just before loading your
~/.emacs`).

> I think there is something wrong
> with this part of my .emacs with respect to emacs -Q:

With `emacs -Q`, Emacs does not call `package-activate-all`, so before
manually loading your `~/.emacs` you may have to manually call
`package-activate-all`.

>> `.eln` files are indexed by the SHA of the corresponding `.elc`, so if
>> there's no `.elc` of if it has changed, you should never get some left
>> over `.eln` file instead.
>
> I noticed a few packages had been updated and both the old and new
> version had eln files in the cache.

Throwing away old `.eln` files is actually a bit difficult to do
automatically, so they tend to accumulate, indeed.  But Emacs should
never load old `.eln`s because when loading a `.eln` file is looks for
it based on the hash of the `.elc` file it would have loaded instead.


        Stefan

Re: "transient-define-suffix" autoload error ?

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Stefan Monnier via Users list for the GNU Emacs text editor
>  <help-gnu-emacs@gnu.org>
> Date: Wed, 19 Jun 2024 17:36:36 -0400
> 
> >> `.eln` files are indexed by the SHA of the corresponding `.elc`, so if
> >> there's no `.elc` of if it has changed, you should never get some left
> >> over `.eln` file instead.
> >
> > I noticed a few packages had been updated and both the old and new
> > version had eln files in the cache.
> 
> Throwing away old `.eln` files is actually a bit difficult to do
> automatically, so they tend to accumulate, indeed.

Right.  But any new Emacs version you install will create a new
subdirectory in the cache, so one can delete old subdirectories when
they are no longer needed (i.e. when you no longer expect to use the
corresponding Emacs version).  Emacs 29 has the command
native-compile-prune-cache, which will delete all the cache
subdirectories except the one used by the Emacs version of the current
session.

> But Emacs should never load old `.eln`s because when loading a
> `.eln` file is looks for it based on the hash of the `.elc` file it
> would have loaded instead.

I think its hash is based on the .el file instead.  And yes, Emacs
should never load a .eln file that doesn't match the current Emacs
version and the corresponding .el file.