[PATCH 3/4] config: only set search.exclude_tags to "deleted; spam; " during setup

[Pieter Praet]

On Sun, 22 Jan 2012 21:34:00 -0800, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> On Mon, 23 Jan 2012 06:05:27 +0100, Pieter Praet <pieter at praet.org> wrote:
> > You definitely have a point, but then again, who are we to assume that
> > the terms "deleted" and "spam" have the *exact* same meaning for
> > everyone?  (also see id:"8739bbo0br.fsf at praet.org")
> 
> Hrm.  I'm not sure I buy this.  Words already have meanings.  If we're
> going to start down a rabbit hole where we have to assume that users are
> making up crazy alternate meanings for words, we're going to run into a
> lot of problems.
> 

True, but we're talking about tags here.  Flexibility is their raison
d'être.  If we're going to impose semi-arbitrary limitations, we do away
with alot of the benefits we were looking for in the first place.

> Notmuch, or at least the emacs interface, already assumes a specific
> meaning for certain terms, like most notably "inbox".  Given that we're
> dealing with english here, I think we have to assume common usage
> meanings for any of the words we're using to describe anything.
> 

Actually, we're only a small step away from being free to use whatever
tag(s) we want for this.  The term "inbox" is hardcoded in only 4
places, all of which are trivial to fix:

- @ binary
  - `notmuch_config_open', where it's only used as a fallback when
    'new.tags' isn't set (and reused to suggest a default value for
    'new.tags' when running setup).

- @ Emacs UI
  - `notmuch-saved-searches' (the function), where it's only used as
    a fallback when `notmuch-saved-searches' (the var) isn't set.
  - `notmuch-search-archive-thread'
  - `notmuch-show-archive-thread-internal'

> This argument breaks a little in regards to "delete" since we're not
> actually deleting anything in the sense of rm'ing it form the
> filesystem, so we're already changing the meaning a bit.  But see below.
> 

[...]

> > IMHO, this is one of those options that should remain disabled until
> > *explicitly* set by the user.
> 
> Ok, but then we're back to the incredibly prolonged discussion we've
> been having about adding "delete" keys.  If we disable this by default,
> but add "delete" keys, the user might be in for a different surprise if
> "deleted" messages keep showing up in searches.
> 
> Basically we have two options as I see it:
> 
> - add keys bindings to add "deleted" tags, and then *also* exclude
>   "tag:deleted" by default.
> 
> - don't exclude anything by default, but then don't add any special keys
>   to handle "deleted" tags.
> 

Adding a key to "delete" messages doesn't necessarily have to mean that
the tag it adds should be hardcoded to "deleted".

For example, our config file could contain something like this:

  #+begin_src conf
    [new]
    tags=unread;inbox;

    [tag]
    deleted=deleted;-inbox;
    archive=-inbox;

    [search]
    exclude_tags=deleted;spam;
  #+end_src

  (where all entries under the [tag] section could be used as
   aliases for "complex" tagging operations)

... and then we could "delete" messages using something like:

  #+begin_src emacs-lisp
    (define-key notmuch-show-mode-map "d"
      (lambda()
        (interactive)
        (notmuch-show-mod-tags
          (split-string
            (notmuch-config-get "tag.deleted") "\n"))
        (notmuch-show-next-open-message)))
  #+end_src

  (`notmuch-show-mod-tags' doesn't exist, of course, but see
   `notmuch-message-mark-replied' for a good example of how
   it could be work...)

> There seemed to be a consensus forming that we in fact did want to add
> the "deleted" key bindings.  [...]

+1.

> [...] If we do that, then I think we should
> generate the config file to exclude "deleted" tags by default.
> 
> jamie.
> 
> PS: when I say "exclude tags by default" I actually mean that the
> setting should be added to the config file upon (re)generation.  Nothing
> should be excluded if nothing is set in the config file.

Exactly!  This is actually the *only* reason I involved myself with this
whole conversation in the first place :)


Peace

-- 
Pieter