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

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> 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
solution.

Eric

anotherfix.diff
Description: Text Data