unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: "Sebastian Spaeth" <Sebastian@SSpaeth.de>
To: notmuch@notmuchmail.org
Subject: Re: Some thoughts about notmuch sync with other agents
Date: Mon, 01 Feb 2010 15:55:21 +0100	[thread overview]
Message-ID: <87y6jd3t0m.fsf@SSpaeth.de> (raw)
In-Reply-To: <87wrz3zl94.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]

REPOSTING, as the previous reply went to Gmane

> One may
> or may not like IMAP for good reasons, the fact is that it is here and
> has allowed users to read mails from various places and terminals,
> keeping important information synced. So I think that notmuch will have
> to live with that, and provide what is required to integrate smoothly
> into this environment.

agreed

> First of all, processing mail with MUA involves some simple logic that
> is shared by most MUA. This is about receiving *new* mails, *reading*
> mail, *replying* to mail and so on... IMHO, this really belongs to the
> mail processing logic and not to the user logic. Hence my first
> request :
>   1: Don't use user tags space to store MUA flags.

I don't really see what you gain by this proposal. I don't necessarily
think it's bad either, but there is no advantage IMHO.

What you propose is basically that those tags are not directly seen by
the user and not modifiable by the user. What's the advantage over
having a small set of "reserved tag keywords"? Your notmuch-capable
editor could still chose to not display "unread" and "deleted" tags but
simply hide deleted mails and show unread mails in bold or so. I simply
don't think it's important how tags are stored and the current scheme is
dead simple which makes it pretty nice.
 
>      That means no more "seen", "unread", "replied" as tags. These are
>      MUA processing *flags*, that must belong to an established set.
>      Tags, on the other hand, are user-land information. So no more
>      [seen, replied, grandma, important] tag sets :)

See above, the mail editor might chose to hide thos MUA processing
flags, but I don't think it is important whether they are hidden by the
user or now. 

Other than that, I agree that "notmuch new" should set a "new" and/or
"modified"tag if it detects a new mail (or a modified one), rather than
the current set of fixed tags that aren't too helpful for 3rd party
scripts.

Sebastian 

[-- Attachment #2: Type: text/plain, Size: 78 bytes --]

Date: Mon, 01 Feb 2010 15:54:57 +0100
Message-ID: <871vh557lq.fsf@SSpaeth.de>

      parent reply	other threads:[~2010-02-01 14:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-27 14:16 Some thoughts about notmuch sync with other agents Paul R
2010-01-30 10:12 ` Michal Sojka
2010-02-01  7:27 ` martin f krafft
2010-02-01 14:55 ` Sebastian Spaeth [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y6jd3t0m.fsf@SSpaeth.de \
    --to=sebastian@sspaeth.de \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).