[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49291: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instanc
From: |
akater |
Subject: |
bug#49291: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform |
Date: |
Thu, 01 Jul 2021 11:54:32 +0000 |
> No, not to the eieio--class but to the new object.
Right, I was confused. I left the word FIXME but rephrased the comment
so that we don't mention the non-existent dflt. At the moment, I'm not
ready to reimplement this with aset and to ensure it would not break by
accident in an obscure manner.
> But could you add a test or two to
> test/lisp/emacs-lisp/eieio-tests/eieio-tests.el ?
I added sort of exhaustive tests for initialization. A complete
exhaustive test would also take :default-initargs and inheritance into
account but I'd rather do this gradually. I did not run tests in Emacs
28 but they pass as is in Emacs 27.
Some :initform's needed a fix (quote), some could be improved (search
for “symbol-value” in the patch).
The necessity to quote should be expected to break some packages, maybe
a lot. E.g. helm contained one unquoted such instance. I already fixed
it; nothing else broke for me so far but it was easy to omit this quote.
If authors get confused about initform workings, it may help to note
that :initform actually expects a *form*, i.e. expression to be
evaluated. The attempt to guess what to evaluate and what not was based
on the wrong premise that CL does that.
0001-lisp-emacs-lisp-eieio.el-initialize-instance-Fix-eva.patch
Description: Fix eval initform
- bug#49291: [akater] [PATCH] lisp/emacs-lisp/eieio.el (initialize-instance): Fix initform,
akater <=