[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Any way to control which articles Gnus summary shows by default?

From: Eric Abrahamsen
Subject: Re: Any way to control which articles Gnus summary shows by default?
Date: Sun, 08 Apr 2018 16:59:13 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eric Abrahamsen <address@hidden> writes:

> Michael Heerdegen <address@hidden> writes:
>> Eric Abrahamsen <address@hidden> writes:
>>> Yes, the whole problem arose from the fact that the write/restore
>>> process isn't recursive. In Emacs 26, the process needed to "look
>>> deeper" inside the objects, and I thought that in doing that I'd been
>>> careful to balance the write and restore process. Apparently I've still
>>> failed to get it right -- though now I'm only seeing quote accumulation
>>> in the secondary tables, not the main :data table.
>> Same here: not in :data, but in :tracker.  But the :tracker data
>> contains sub-hashtables, while :data doesn't.
> Okay, the immediate problem is that `eieio-override-prin1' is recursive
> inside hash tables (it adds quotes to hash table values to an arbitrary
> depth), but the mirror-image recovery process inside
> `eieio-persistent-validate/fix-slot-value' is not recursive, and only
> examines one layer.
>>> The whole process is ad hoc and largely unnecessary. In #29541 I've
>>> started working on a more general solution that would be actually
>>> recursive, and also not work so hard. I've had second thoughts about the
>>> patch I posted there, but I think the general direction is correct.
>> What would happen if we just don't add quotes when writing lists?
> The solution will either be not adding quotes at all, or making the
> read/restore/recovery process equally recursive. Stand by...

And the solution needs to be making the process equally recursive,
because right now it's entirely possible that other packages could start
using eieio-persistent with weird data structures, and fall afoul of
this asymmetry. It's not just about quotes: if another package starts
stashing EIEIO objects inside nested hash tables, they will be written
correctly, but read incorrectly.

My next stab at a fix is in the attached patch. Michael, assuming I
haven't exhausted your patience, would you mind giving this a try? I do
believe this is the right solution, or at least the best minimal


Attachment: anotherfix.diff
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]