From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 046594048D3 for ; Fri, 12 Mar 2010 07:01:14 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[AWL=1.191, BAYES_00=-2.599, RDNS_DYNAMIC=0.1] autolearn=no Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGcTOT2MRAcA for ; Fri, 12 Mar 2010 07:01:12 -0800 (PST) Received: from hackervisions.org (67-207-143-141.slicehost.net [67.207.143.141]) by olra.theworths.org (Postfix) with ESMTP id 2D4B14048D0 for ; Fri, 12 Mar 2010 07:01:12 -0800 (PST) Received: from ool-18bd392a.dyn.optonline.net ([24.189.57.42] helo=localhost) by hv with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Nq6MR-0006xh-8L; Fri, 12 Mar 2010 10:01:11 -0500 From: James Vasile To: Michal Sojka , notmuch@notmuchmail.org In-Reply-To: <87iq92m12o.fsf@steelpick.localdomain> References: <87aauhp9kk.fsf@hackervisions.org> <87pr3bm2sn.fsf@steelpick.localdomain> <87fx46hq7w.fsf@hackervisions.org> <87ljdyn7zi.fsf@steelpick.localdomain> <876352hccg.fsf@softwarefreedom.org> <87iq92m12o.fsf@steelpick.localdomain> Date: Fri, 12 Mar 2010 10:01:04 -0500 Message-ID: <87zl2deg9b.fsf@hackervisions.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [PATCH] Change From and Bcc when creating reply draft buffer X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:01:14 -0000 On Fri, 12 Mar 2010 08:49:35 +0100, Michal Sojka wrote: > On Thu, 11 Mar 2010, James Vasile wrote: > > On Thu, 11 Mar 2010 17:22:41 +0100, Michal Sojka wrote: > > > thanks for clarification. It all sounds reasonable. The only problem I > > > can see now is that if I create a new account on my machine and run > > > emacs there, then the value of user-mail-address is @ > > > which doesn't refer to existing mailbox. I think that the header should > > > only be rewritten if these variables are known to have valid values. Do > > > you know how to do this? > > > > > > > I explicitly set these in my .emacs file, so I don't do any detection. > > If you could define "valid" I suppose you could test for such things. > > > > Something like the following works for me. I run mail-profile-foo with > > M-x or run it automatically with profile-guessing/setting routines. > > When I get the system ironed out, I'll emit patches and a wiki entry. > > > > (defun message-mode-set-profile () > > (save-excursion > > (when (string= "message-mode" major-mode) > > (goto-char (point-min)) > > (when (re-search-forward "^From: " nil t) > > (kill-line) > > (insert (format "%s <%s>" user-full-name user-mail-address))) > > > > (goto-char (point-min)) > > (when (re-search-forward "^Bcc: " nil t) > > (kill-line) > > (insert (format "%s <%s>" user-full-name user-mail-address)))))) > > > > (defun mail-profile-hv () > > (interactive) > > (setq mail-host-address "hackervisions.org" > > user-full-name "James Vasile" > > message-sendmail-extra-arguments '("-a" "hv") > > user-mail-address "james@hackervisions.org") > > (message-mode-set-profile) > > user-mail-address) > > (mail-profile-hv) > > > > > > Hmm, I understand. My worry about this approach is the following: Now it > is very straightforward to start using notmuch. You only answer a few > questions when you run notmuch for the first time and then it works. If > we apply your patch, some additional configuration is needed and a > novice might not know how to do it. I disagree as to how much time notmuch currently takes. To get a workable setup, you need to answer a few questions, setup offlineimap, write a tagging script, setup up folders, apply a bunch of patches, etc. I've been telling people to wait 6 months instead of trying notmuch. That's based on how much work it is to setup, incomplete MUA, bugs, etc. > So at least notmuch should tell the user what and where needs to be > configured. Or better, provide some sane default which can be overridden > in a way you want it. > > That's only my opinion. I personally would have no problem with > additional configuration, but on the other side I like programs which do > not steel my time if it is not necessary. That's a fair point. I hope notmuch gets easier over time, and one of the things I'd like to implement is sane defaults. As notmuch gets more user friendly, I'd like to make the pieces I write less onerous to configure. For example, I have some stub code for a default profile that pulls values from ~/.notmuch. Then if the user doesn't do the setup, things should be not much different than they are now. -J