[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

Hi Antoine,

I had started on a draft of this email before receiving your latest
update; however, I the info below is still relevant.

Antoine Beaupré <anarcat@debian.org> writes:

> I still need to get to the office to confirm the fix, but this totally
> makes sense. I have a very old Emacs configuration, which I've been
> carrying for over two decades at this point. Cruft is bound to creep up
> in there, and I'm actually surprised things still work in any meaningful
> way. :)

:-) I feel that way about some of my config too!  And I think you'll
agree that Emacs is great because it accommodates this, and that its
config and customisation becomes more of a "story" than the way some
people are using "story" as a synonym for "new user experience".  It's
tangential to this bug, but I'm curious what you think about the new
trendy "literate programming" style configs?  (I'm not sure if/when I
will switch to one, but I think it's a cool idea!):


> I'm still kind of confused. What's the proper way to (say) setup package
> repositories and then `use-package'?

If I understand the new Emacs init process correctly, then a simplified
form describing the init process looks something like this:

  (lambda ()
    (load early-init.el)
    ;; I suspect the init for the UI goes here
    (package-initialize)  ;; automatic
    (mapc 'load (list of all supported init.el locations)))

I'm not a `use-package` user, but I think use-package stuff is supposed
to continue be configured from a supported init.el location...rationale
being that `use-package` seems like it ought to be

> In other words, what's the modern equivalent of this in my
> `.emacs.d/init.el`?
> (when (require 'package nil t)
>   (setq-default
>    load-prefer-newer t
>    package-enable-at-startup nil)

Please see note in previous emails about the location where
`package-enable-at-startup` *must* be set.  There may also be other bits
of your init.el that must now be moved to early-init.el.  Sorry, I don't
have a list...  I trust the docstrings, so I don't think this is an
optional thing that can be ignored.

>   (when (< emacs-major-version 27)
>     (package-initialize))
>   (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/";)
> 			  ("melpa" . "https://melpa.org/packages/";)))
>   ;; in elpa-use-package debian package since stretch
>   (unless (package-installed-p 'use-package)
>     (package-refresh-contents)
>     (package-install 'use-package)))
> (eval-when-compile
>   (require 'use-package)
>   (setq-default
>    use-package-always-defer nil
>    use-package-always-ensure t))
> Note that I added this `(when (< emacs-major-version 27)' blob to try to
> workaround the bug. But now it seems that this packaging stuff might
> belong to early-init.el? What if I want this config to still work in
> Emacs 26?

There are a couple of ways to do this, take your pick ;-)

1. Use early-init.el on Emacs 27 hosts and add special cases everywhere
it may be required in init.el (icky, imho!)
   * Note, init.el will need at least one special case for `package-initialize`.
2. Move what must go in early-init.el to that file, and then (load
early-init.el) at the top of init.el for emacs < 27 hosts.
   * I wonder if there will be corner case breakage with this?
3. If you don't need Emacs 25, that means you're on buster, which means
Emacs 27 is available from buster-backports.
   * This is the option I chose, to keep my config as simple as possible.
   * Please note there's a IMHO RC (to backports) bug in the declared
     dependencies.  IIRC the workaround is to manually 'apt install -t
     buster-backports emacs-common'.  It might have also been this
     issue: https://lists.debian.org/debian-backports/2021/03/msg00012.html
     Sorry, I can't clearly remember...
   * Buster-backports is also missing emacs-common-non-dfsg for Emacs 27
     :-(  Luckily it's arch:all so can be installed from unstable.
   * Additionally, take care to either remove elpa-org, or upgrade it to
   the version in unstable, since IIRC the version bundled with Emacs 27
   is newer than the version in buster.
> Thanks for holding my hand through the new millenia. ;)

Anytime!  Oh, one more thing, I've read about how old elc files (in
$HOME) have caused problems this release, so it's probably also a good
idea to erase them all and re[byte]compile them.


Attachment: signature.asc
Description: PGP signature

Reply to: