Lars Ingebrigtsen writes: > Eric Abrahamsen writes: > >> I don't know why that happens, given that the entry in the hashtable and >> the alist are identical lisp objects, or at least they are everywhere >> else. But at least the solution is in sight! > > Great. :-) I think it has to be done the ugly way -- setting the hashtable and alist separately. The problem (I write this more as part of digesting the issue than anything else) is that the alist is full of elements that look like '("group" 4 ((1 2 3) (4 5 6))), whereas the corresponding value in the hashtable looks like '(25 ("group" 4 ((1 2 3) (4 5 6)))). The alist element is `eq' to the `cadr' of the hashtable value: they're the same list object. If you reach inside that list and change values (ie set 4 to 7), they remain the same list, and the change is reflected in both hashtable and alist. If you replace the entire ("group"...) list, in the hashtable, it is no longer the same object as that in the alist, and you get divergence. This seems sensible in hindsight, but took me quite a while to figure out. 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. 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... Eric