On Sun, 22 Jan 2012 21:34:00 -0800, Jameson Graef Rollins <jroll...@finestructure.net> wrote: > On Mon, 23 Jan 2012 06:05:27 +0100, Pieter Praet <pie...@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....@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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch