Some ideas for future development

[atomontage]

I will work on some of these myself, I'm posting here to see if there's additional interest.

• Context-specific completion where it makes sense (e.g. tags)
• elfeed-search-set-{entry,feed}-title should show the old title,feed
• Let people do their own formatting for elfeed-log entries (by exposing a `format' function)
• Show db sync status in header or mode-line

Some nice things that can be implemented on top of the existing API and features exposed by the elfeed DB:

• Comments for entries that are saved in the DB. A tag can be used to indicate if an entry has comments or not. Comments are saved/shown/edited and kept track of as a single entity per elfeed entry.

• Entry archiving via external process (think Chrome -> save complete webpage as). Scenario being that you're in elfeed-search, hit a key and a customizable external browser will fetch/save the target post and all its assets under a customizable root directory (say ~/.elfeed/archived/). A tag can be used to indicate if an entry has been archived or not.

[skeeto]

Context-specific completion where it makes sense (e.g. tags)

Oh, good idea! Filter editing could use some work in general. I'm still not sure if I'm happy about the current character classes (e.g. I decided that + and - are a word constituents, so they're traversed/handled just as if they were letters).

elfeed-search-set-{entry,feed}-title should show the old title,feed

Sounds good to me. I don't use that interface much, so it hasn't gotten much attention.

Let people do their own formatting for elfeed-log entries

Sounds fine.

Show db sync status in header or mode-line.

That's a very good idea. I've personally gotten (too) comfortable with tracking that information in my head, but it should somehow be communicated. Maybe the appropriate place is the "CH" modified indicator on the mode-line (which is perhaps what you meant).

Comments for entries that are saved in the DB.

The way I see it, the only change in Elfeed core would be the indicator in the search listing. Comments should be stored as just another item in the meta plist (:comments), and the interface to comments (editing, viewing) would be its own mode and buffer.

It could basically be done as a pure extension, except for the difficultly in making a minor change to the search listing (which currently is either the default, or a wholesale re-implementation via elfeed-search-print-entry-function).

Entry archiving via external process

This has been brought up before. So far I've left it as something to be done as an extension. Though there may be value in leveraging the existing content database (elfeed-ref, elfeed-deref) — except that a locally-mirrored site (ala wget -m) isn't just a hunk of content, but a loose collection of interdependent files.

[atomontage]

Re: sync indicator, I'd make it more obvious than reusing the Emacs buffer-modified thingy. Glad you like the rest of the improvements.

Regarding the last 2 (comments and archiving), I don't think they should be implemented as part of elfeed itself, I just posted here about them to see if they've come up before and get additional opinions.

You've done a great job with the code which is clean and well-commented, an oasis amidst so much crap out there. If I was in your shoes, I'd strive to keep it "tight" and not bloat it with extraneous functionality that will not directly improve things everytime someone uses the application (my personal metric for when to add features). Elfeed is also the first RSS client that I can stand using (and also one I'm willing to spend personal time to extend!) so props for that too.