0

Q: why do I get errors when calling a command from a specific buffer, but not in any other buffer?

Scratch all of what I had previously said about call-interactively (see strikethrough below for reference). It's not even remotely that.

I've done some additional investigation, and have narrowed the problem down to something even more baffling:

  1. visit buffer mymode.el, which defines some classes
  2. call eval-buffer on mymode.el
  3. call initialize-my-mode command
  4. get error slot-boundp: Wrong type argument: eieio-object-p, #s(my-class-constructor "slot-1" "slot-2" "slot-3" "slot-4")

However, if, after calling eval-buffer, I switch to any other buffer besides mymode.el and call the initialize-my-mode command, I get no errors.

Why would I get eieio errors when I call a command when visiting a specific buffer, but not any other buffer?

I have zero idea what could be happening here. I know it would be helpful to provide a minimal working example, but the classes are buried so deeply inside this mode that I cannot put one together in a timely fashion. I have to punt on tracking this bug down due to some big family commitments (toddler + newborn in the house, sorry!).

I'll be going back to the stable Emacs 26, but I'll leave this item up here in case anyone has any idea what's going on.

PS Apropos one of the bug reports in the comments, I have eieio-backward-compatibility set to nil.

Q: are there any differences between M-x command and (call-interactively #'command)?

I have an obscure bug I'm trying to hunt down, and can't even begin to think of how to do it.

the summary version

Here's the short version, abstracting away the details. I have an interactive command some-command that takes no arguments. When I call it via execute-extended-command (i.e., M-x some-command), I get the error message some error message.

When I call it via elisp as (call-interactively #'some-command), it runs without error. Likewise, when I call it via straight elisp as (some-command), it runs without error.

what's happening here?

What could possibly be causing the command to throw an error when invoked via M-x but not any other way?

the error message in sketch

For the morbidly curious, the error message is as follows, abstracting away some of the idiosyncrasies:

slot-boundp: Wrong type argument: eieio-object-p, #s(my-class-constructor "slot-1" "slot-2" "slot-3" "slot-4")

FWIW

This error started to show up when I upgraded to the snapshot version of Emacs (27.0.50). I've had other problems with eieio in the process.

  • Can you provide a backtrace? – NickD Jun 14 at 20:25
  • The two are certainly different. Why not M-x debug-on-entry execute-extended-command and walk through it in the debugger to see why it raises the error? And you might want to show a little code - we don't even see your interactive spec. – Drew Jun 14 at 20:37
  • Do you see the problem if you start Emacs using emacs -Q? And you don't/didn't see it with emacs -Q on an actual release? – Drew Jun 14 at 20:39
  • Hi, this seems like it could be a similar issue to github.com/magit/forge/issues/159, which is caused by my change to semi-fix for Bug#29220. Could you elaborate on your problem (either here or on emacs-devel or in an Emacs bug report)? Since my change is causing people trouble, I might have to revert it on emacs-26 at least, so I'd like to have more details. – npostavs Jun 15 at 4:06
  • @npostavs: thanks, it's something that appears to be eieio related, but I'm completely out of ideas on what could be causing this problem. I only discovered this bug in the process of trying to fix the previous eieio related bug you helped identify (thanks again!). It's definitely an emacs-27 snapshot problem, as I'm not seeing it in emacs 26.1. – Dan Jun 22 at 18:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.