unhammer / gnus-recent

Avoid having to open Gnus and find the right group just to get back to that e-mail you were reading.

gnus-recent

Avoid having to open Gnus and find the right Group just to get back to that e-mail you were reading.

Or hit a key while reading one article to pop back through the stack of previously read articles, even if they were in a different Group.

Or insert a link to a recently read e-mail in an org-mode buffer by just picking one with completion:

Installation

If you use MELPA, you can just do M-x list-packages, find gnus-recent in the list and hit i x.

The Melpa packages doesn’t include the ivy/helm stuff, you’ll have to clone the repo if you want those.

Configuration

Require and bind whatever keys you prefer to the interactive function:

(use-package gnus-recent
  :ensure t  ; if you want it from MELPA
  ; :load-path "~/src/gnus-recent" ; if you're running from a git clone
  :demand t ; so that it's loaded after gnus even though we use :bind
  :after gnus
  :bind (("<f3>" . gnus-recent)
         :map gnus-summary-mode-map ("l" . gnus-recent-goto-previous)
         :map gnus-group-mode-map ("C-c L" . gnus-recent-goto-previous)))

If you use Embark, add the following to be able to insert org links on l:

(add-hook 'minibuffer-setup-hook #'gnus-recent-embark-minibuffer-hook)

Usage

After reading some articles in Gnus and then doing whatever, doing gnus-recent-goto-previous will open the last read article and rotate the list, so you can keep calling it to go further back.

Doing gnus-recent will let you pick an article to re-open.

If you use gnus-recent-ivy, you can hit M-o l to insert an org-mode link to the article instead.

Alternatives

• gnus-notes is a fork of gnus-recent which adds some more features (persistence, get a Helm list of Gnus links of the current Org subtree, etc.)
• The Gnus Registry might be persuaded to do gnus-recent’s job if you ask it nicely

gnus-recent's Issues

Helm integration

I found your gnus "breadcrumbs" idea great!

I use gnus... it is something I always felt the need for. Just like you describe.
Thank you for gnus-recent.
I use Helm instead of Ivy... so wrote up a first implementation for gnus-recent-helm.el. It seems to work well.
I am happy to contribute the code to guns-recent.

the code is here:
https://github.com/deusmax/gnus-recent/blob/helm/gnus-recent-helm.el

Include open draft buffers as well

gnus-registry as an alternative to gnus-recent

According to @deusmax , gnus-registry some of the same as gnus-recent, but of course doesn't have the ivy/helm interfaces.

Would it be possible to build a gnus-recent-like interface on top of gnus-registry? That would give some nice features like:

• persistence (stored to ~/.gnus.registry.eieio )
• integration with gnus-bookmarks

Are there other things we'd get? I haven't used gnus-registry nor gnus-bookmarks myself.

(If we do change the "back-end", it may be better to do it as a new package, unless it can be done without any backwards-incompatible changes.)

Depend on ol-gnus instead of org-gnus

org-gnus.el has been renamed to ol-gnus.el, see https://code.orgmode.org/bzg/org-mode/commit/499c0a50cc4b11e37b91374af23cb27ab8fc20d2, so you should depend on ol-gnus. Because the change to Org has not made it into a release yet, you might want to soft depend on both features for the time being.

`b' in ivy should go to BBdB entry

We should have a gnus-recent-show-in-bbdb which shows the sender's BBdB entry (maybe also gnus-recent-show-all-in-bbdb which does the same for sender+all recipients).

gnus-recent fails to open groups under gnus-secondary-select-methods

I have 2 nnimap accounts configured with my Gnus.

• The first is configured as a gnus-select-method. These emails open fine.
• The second is configured as a gnus-secondary select-methods. These fail to open.

Typical error message like this:

Couldn’t fetch article <[email protected]>

The org-links generated by org-recent work fine for both groups !!

Gnus v5.13,
Emacs 27.0.50

Don't track digest-group / C-d articles

In a Summary, C-d / M-x gnus-summary-enter-digest-group on a multi-part article will open a digest group with all the parts. We shouldn't track this (it doesn't work anyway, and is just annoying noise in the recent list).