gnus-registry as an alternative to gnus-recent

[unhammer]

gnus-registry as an alternative to gnus-recent

[deusmax]

I don't really think gnus-registry is an alternative to gnus-recent.
I think there are many similarities in trying to track the article locations. Indeed they use similar methods of using much the same hooks provided by gnus to accomplish this.
The difference is that gnus-registry tries to get all the articles (during spooling) that bloats it up and slows it down. It also tries to do other (grand) things, like article splitting etc. that are probably not relevant much today .
In addition, gnus-registry lacks a user interface, so the user doesn't know what to do with it.

I feel that gnus-registry can provide some good ideas to gnus-recent. To build a gnus-recent-like interface on top of gnus-registry, will carry its bloat too (and may have other complications).

As for the gnus-bookmarks data format, it probably does have some advantages.

[deusmax]

The "featuretrack" branch on my repo, where I' trying some ideas discussed before.. The format of the gnus-recent--articles-list is changed to an assoc list.

The main new things are:

• all operations (add, update, delete) are based on the message-id and are much more reliable.
• display gnus group by default.
• display the To, Cc fields, by cycling with M-<up>
• forget articles without quitting using the C-j (helm persistent action key)
• rudimentary read, write of the gnus-recent-articles-list data to file. Rudimentary because the write is user activated. Persistence is now possible if desired.
• having the To, Cc fields, can interact with bbdb (todo).

As I'm a helm user, the above are implemented on the helm interface.

[unhammer]

I don't really think gnus-registry is an alternative to gnus-recent.

I'll close this then.

The "featuretrack" branch on my repo

which I guess is what turned into https://github.com/deusmax/gnus-notes =D