GNU bug report logs - #28587
26.0.60; Don't write object name strings in object-write method

Previous Next

Package: emacs;

Reported by: Eric Abrahamsen <eric <at> ericabrahamsen.net>

Date: Sun, 24 Sep 2017 21:12:02 UTC

Severity: minor

Tags: patch

Found in version 26.0.60

Done: Eric Abrahamsen <eric <at> ericabrahamsen.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: 28587 <at> debbugs.gnu.org
Subject: bug#28587: 26.0.60; Don't write object name strings in object-write method
Date: Sat, 21 Oct 2017 23:29:00 -0400
> If we're going to ignore them, we might as well not write them to begin
> with.

Agreed.

> --- a/lisp/emacs-lisp/eieio-base.el
> +++ b/lisp/emacs-lisp/eieio-base.el
> @@ -255,8 +255,11 @@ eieio-persistent-convert-list-to-object
>  Note: This function recurses when a slot of :type of some object is
>  identified, and needing more object creation."
>    (let* ((objclass (nth 0 inputlist))
> -	 ;; (objname (nth 1 inputlist))
> -	 (slots (nthcdr 2 inputlist))
> +	 ;; Earlier versions of `object-write' added a string name for
> +	 ;; the object, now obsolete.
> +	 (slots (nthcdr
> +                 (if (stringp (nth 1 inputlist)) 2 1)
> +                 inputlist))
>  	 (createslots nil)
>  	 (class
>  	  (progn

This looks good, feel free to install it into `master'.

> diff --git a/lisp/emacs-lisp/eieio.el b/lisp/emacs-lisp/eieio.el
> index 75f1097acf..448d5e6fe2 100644
> --- a/lisp/emacs-lisp/eieio.el
> +++ b/lisp/emacs-lisp/eieio.el
> @@ -874,8 +874,6 @@ eieio-print-depth
>      (princ (make-string (* eieio-print-depth 2) ? ))
>      (princ "(")
>      (princ (symbol-name (eieio--class-constructor (eieio-object-class this))))
> -    (princ " ")
> -    (prin1 (eieio-object-name-string this))
>      (princ "\n")
>      ;; Loop over all the public slots
>      (let ((slots (eieio--class-slots cv))

This is more problematic since data generated with this hunk will be
incompatible with an Emacs which doesn't have the other hunk applied.
So I think this should be conditional on a defcustom and by default this
defcustom should cause the code to still behave as before.


        Stefan




This bug report was last modified 7 years and 186 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.