[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Putting 2fddfb7ce770f into emacs-26?
From: |
Eli Zaretskii |
Subject: |
Re: Putting 2fddfb7ce770f into emacs-26? |
Date: |
Wed, 08 Nov 2017 17:54:14 +0200 |
> From: Eric Abrahamsen <address@hidden>
> Date: Tue, 07 Nov 2017 18:29:06 -0800
>
> I know it's a bit late in the day, but would it be okay to cherry-pick
> 61313f058c7a899c2fbce055d21 from master to emacs-26?
There's no such commit on master, I guess you took the SHA1 from some
local branch of yours. But I think I've succeeded to guess what you
meant. It is the commit below, right?
commit 2fddfb7ce770f61313f058c7a899c2fbce055d21
Author: Eric Abrahamsen <address@hidden>
AuthorDate: Sun Oct 22 07:59:29 2017 -0700
Commit: Eric Abrahamsen <address@hidden>
CommitDate: Sun Oct 22 07:59:29 2017 -0700
Handle object string name in eieio-persistent-convert-list-object
* lisp/emacs-lisp/eieio-base.el (eieio-persistent-convert-list-to-object):
Starting to phase out the printing of object names in
`object-write', handle either case.
> It's related to how EIEIO objects are written to file. Previously, the
> written representation included a string label, which was later
> obsoleted. Current emacs-26 code *assumes* the presence of a string
> label: it discards it, but will fail without it.
>
> The change in 61313f058c7a899c2fbce055d21 checks for the label and
> conditionally ignores it, making the code more resilient when reading
> objects written by a wider range of Emacs versions. A bit of
> future-proofing.
>
> Is that acceptable for emacs-26?
If you meant the above commit, then are you absolutely sure the second
slot can never be a string unless it's the object name? If you are,
then this is okay for emacs-26.
Thanks.