another attempt to add delete functionality in emacs

[Jani Nikula]

On Tue, 10 Jan 2012 19:12:16 -0800, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> On Tue, 10 Jan 2012 16:01:32 -0400, David Bremner <david at tethera.net> wrote:
> > Just thinking out loud here, but it does seem a bit unfortunate to me
> > that it represents a pretty fundamental divergence between the CLI and
> > the emacs interface. Mind you, I guess one could make the same argument
> > about the libs versus the CLI. Lack of configuration information in the
> > library (possibly among other reasons) makes this not too nice to
> > support in the current library either.
> 
> I think a consensus has formed that this functionality (automatically
> suppressing messages with certain tags from searches) is better left to
> the CLI, rather than implementing it just in the emacs UI.
> Unfortunately I'm not going to get to that any time soon.

I could have a go at it, but I can't make any promises about getting to
that any time soon either. So what if emacs ui goes head first and does
something that should be done in the CLI in a perfect world? If it's
added properly, it can be taken out if/when this pops up in the CLI.

Also, there already *is* filtering for "all tags" list. See
notmuch-hello-tag-list-make-query. How about having something like that
for saved searches? I know it's not the same as your original, but it's
middle ground...

> However, without that functionality, I really see no reason why we
> should be adding any built-in support for adding "deleted" tags in the
> emacs UI.  Without the CLI change, "deleted" tags aren't handled any
> differently than any other tag, so why should the default emacs UI care.
> If users want to bind keys to special tagging operations, they can do so
> for themselves [0].

In fact, "deleted" used to be special, but that was, err, deleted
because it had problems: 2c262042ac174d7bc96d6035ab9c88bd0abe7f35. If
that ever gets fixed, "deleted" would be special again.


BR,
Jani.