* Putting 2fddfb7ce770f into emacs-26?
@ 2017-11-08 2:29 Eric Abrahamsen
2017-11-08 15:54 ` Eli Zaretskii
0 siblings, 1 reply; 3+ messages in thread
From: Eric Abrahamsen @ 2017-11-08 2:29 UTC (permalink / raw)
To: emacs-devel
I know it's a bit late in the day, but would it be okay to cherry-pick
61313f058c7a899c2fbce055d21 from master to emacs-26?
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?
Thanks,
Eric
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Putting 2fddfb7ce770f into emacs-26?
2017-11-08 2:29 Putting 2fddfb7ce770f into emacs-26? Eric Abrahamsen
@ 2017-11-08 15:54 ` Eli Zaretskii
2017-11-08 17:19 ` Eric Abrahamsen
0 siblings, 1 reply; 3+ messages in thread
From: Eli Zaretskii @ 2017-11-08 15:54 UTC (permalink / raw)
To: Eric Abrahamsen; +Cc: emacs-devel
> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> 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 <eric@ericabrahamsen.net>
AuthorDate: Sun Oct 22 07:59:29 2017 -0700
Commit: Eric Abrahamsen <eric@ericabrahamsen.net>
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Putting 2fddfb7ce770f into emacs-26?
2017-11-08 15:54 ` Eli Zaretskii
@ 2017-11-08 17:19 ` Eric Abrahamsen
0 siblings, 0 replies; 3+ messages in thread
From: Eric Abrahamsen @ 2017-11-08 17:19 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> 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 <eric@ericabrahamsen.net>
> AuthorDate: Sun Oct 22 07:59:29 2017 -0700
> Commit: Eric Abrahamsen <eric@ericabrahamsen.net>
> 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...
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-11-08 17:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-08 2:29 Putting 2fddfb7ce770f into emacs-26? Eric Abrahamsen
2017-11-08 15:54 ` Eli Zaretskii
2017-11-08 17:19 ` Eric Abrahamsen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.