bug#36341: 27.0.50; Reading from the Gnus dribble file leaves data inconsistent

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 07/08/19 18:22 PM, Lars Ingebrigtsen wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I think `gnus-group-set-info' is the only place that happens, so it
>> isn't too terrible to just explicitly set both hashtable and alist in
>> that function. I've attached the commit that does that.
>
> Sounds good -- please apply.

Cool, will do.

>> My plan for avoiding this class of errors in the future is to change the
>> representation of Gnus groups from lists to EIEIO objects. Then
>> `gnus-newsrc-alist' would merely be a disk serialization format, and the
>> hashtable would be the source of authority. That would also make the
>> "dummy.group" unnecessary. But let's see if I get there, and if the
>> changes are accepted...
>
> The whole point of that awkward structure is to allow
> inserting/removing/updating groups from the list-of-subscribed-groups as
> an O(1) operation.  Updating is still fine as O(1) with just a hash
> table, but without the point-at-the-previous-element list, you can't
> remove the elements, or add new elements before the group, as an O(1)
> thing.

Okay, I get that. But I wonder how important it is that add/delete
operations be so efficient? Does subscription/unsubscription happen so
often that it needs to be fast? As for sorting, in current master code
sort-order is kept in `gnus-group-list' (when topic mode is off) and
`gnus-topic-alist' (when it's on), so we're already sorting using plain
lists of strings.

In fact, right at the moment, there's already no need for the ordering
in `gnus-newsrc-alist'. All of the "(while (setq info (pop newsrc))"
loops could be replaced right now with "(dolist (g gnus-group-list)
(setq group (gnus-get-info g))"

Eric