Re: Putting 2fddfb7ce770f into emacs-26?

[Eric Abrahamsen]

Eli Zaretskii <address@hidden> writes:

>> 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?

Weird, I got the right hash in the subject heading, but somehow...

>   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.

I'm pretty sure, yes. All slots are written as pairs of :slot-name "slot
value", and there's currently no way for any odd-numbered element to be
anything but a keyword, except for the first one in this "object name"
case.

Away we go...