From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.96.142.65 with SMTP id ru1csp70512qdb; Sun, 30 Mar 2014 13:47:41 -0700 (PDT) X-Received: by 10.60.62.34 with SMTP id v2mr4049965oer.37.1396212460554; Sun, 30 Mar 2014 13:47:40 -0700 (PDT) Return-Path: Received: from rubyforge.org ([50.56.192.79]) by mx.google.com with ESMTP id do5si10369800oeb.26.2014.03.30.13.47.40 for ; Sun, 30 Mar 2014 13:47:40 -0700 (PDT) Received-SPF: pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 50.56.192.79 as permitted sender) client-ip=50.56.192.79; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 50.56.192.79 as permitted sender) smtp.mail=sup-devel-bounces@rubyforge.org; dkim=neutral (no key for signature) header.i=@schmeiser.org Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 9DF522E19A; Sun, 30 Mar 2014 20:47:41 +0000 (UTC) Received: from origin.schmeiser.org (origin.schmeiser.org [50.116.59.107]) by rubyforge.org (Postfix) with ESMTP id 546C82E18A for ; Sun, 30 Mar 2014 20:47:32 +0000 (UTC) Received: from [10.0.1.8] (c-174-63-120-188.hsd1.ma.comcast.net [174.63.120.188]) by origin.schmeiser.org (Postfix) with ESMTPSA id 3E1D6197D1 for ; Sun, 30 Mar 2014 16:47:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=schmeiser.org; s=default; t=1396212450; bh=rumJBVU9dYGcDToux8Fi7Z1yANenptZgez/R2caWe80=; h=Subject:From:In-Reply-To:Date:References:To:From; b=vljZgzPXawa0k4cKs1eQLQDKP2WXQ/xJzkOLikPj+DrdjCsNs1of4UFMI6rIJIWqZ TYsvJSr0IgLka8JbzTwR4csen62NpdazFZuHS/TymYATOOptRbaxjJnnBw4eW2FF9x zatjnq6s2Cx+huKoR9O+g4iUPUPy3zPHGtalG11k= Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Steven Schmeiser In-Reply-To: <1396168444-sup-8010@email.archlab.tuwien.ac.at> Date: Sun, 30 Mar 2014 16:47:37 -0400 Message-Id: <9CF97884-262B-4CAA-951C-D359C331AC3F@schmeiser.org> References: <1396168444-sup-8010@email.archlab.tuwien.ac.at> To: Sup developer discussion X-Mailer: Apple Mail (2.1874) Subject: Re: [sup-devel] use-mail branch and other work X-BeenThere: sup-devel@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sup developer discussion List-Id: Sup developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: sup-devel-bounces@rubyforge.org Errors-To: sup-devel-bounces@rubyforge.org Hi Martin, Here is what I do to go back and forth between sup and vim while composing = a message. Launch sup with a script... #!/bin/sh tmux -2 new-session -d -s mail -n 'sup' "export TERM=3Dscreen-256color; sup" tmux select-window -t 1 tmux attach-session -d -t mail Use an async-edit hook: system '/Users/steve/.bin/supCompose.sh ' + file_path where supCompose.sh is #!/bin/sh tmux new-window -n compose "vim +/^$ -f -c 'normal o' -c 'startinsert' $1" Then I use the async edit mode when replying to messages. It would be nice= for sup to have an option to always use async edit, but this gets me by. steve On Mar 30, 2014, at 5:51, Martin B=E4hr = wrote: > hi, > = > i'd like to introduce what i am working on and some ideas that i have for= sup. > = > first of all, i was very enthusiastic when i discovered sup (i was checki= ng out > a fork of mutt, which was including notmuch, which was inspired by sup. t= he > mutt fork or notmuch were not really interesting to me, but sup is!) > = > i have been using mutt since more than 15 years, and in recent years i ha= ve > been running more and more into limitations. > i knew knew right away that sup could be a platform to overcome those > limitations. i was even more delighted when i found out that several of t= he > mutt limitations i ran into are already solved in sup. > = > ongoing work: > add support for a "new" state that is different from unread. > the idea here is that the new state of a message can be cleared without > reading the message or marking it as read. this distinction is important > because i have lots of old unread mail, and so i can't see where i have > actual new mail. > i don't want to mark everything as read because occasionally i am search= ing > for an old message where i read about something specific, which is hard = if i > can't tell the difference between what i read and what i didn't read. = > not to mention that it is very hard to mark 500+K messages as read. > = > use the use-mail branch and fix problems as i discover them. > i stumbled into this by accident. i tried use-mail because current stabl= e and > develop branches have problems on debian 6. as a result i discovered tha= t the > use-mail branch is stable enough for my needs. since this branch is > inevitably the way forward given that RMail is dead, i figured that my t= ime > is better spent fixing my problems here, and avoid RMail alltogether. > = > some ideas: > i'd like the ability to apply a label change to all messages that matc= h a > given search, not just the ones loaded into the buffer. > = > i have imported a lot of uncategorized messages from my mutt inbox, and i > want to make use of sup's tagging to group them. instead of loading all > messages in a search with !! it would be nice to just let sup tagg those > messages in the background. > = > i am using procmail still to prefilter mail. it's going to take a whil= e to > switch to a sup based filtering, and i am not sure i even want that, at = least > not until sup can reliably filter mails into folders. > = > procmail also filters spam, and in sup those sources are automatically t= agged > as spam. my spam filters are aggressive, and do have false positives. sup > should be able to determine that any message that is a reply to a known > non-spam message is also not spam, and should thus not apply the spam la= bel > to this message. > = > the same goes for any message from an email address that i have sent mai= l to. > iaw, all my contacts should automatically be whitelisted. > = > occasionally, when writing mail i need to look up something in other m= ails. > with mutt i "solved" this by running two instances of mutt in parallel. = (the > main reason for that was to be able to switch between the inbox and other > folders without having to reload the inbox all the time. sup solves that= part > nicely by allowing me to switch between buffers.) > = > so what i want here is some way to switch back and forth between vim and= sup. > possibly this can be done with tmux or screen by opening vim in another > window. > = > i'd like to treat saved searches as virtual folders. they should be in= a > combined list with labels, and i'd like to be able to open them by typin= g the > name in the search prompt. > = > related to this and above, i'd like to auto-label searches. instead of > writing a hook, i'd like to just say: always label messages matching this > search, and have sup generate the necessary hook by itself > = > i have some more ideas that don't come to mind right now. > = > you can find my work on https://github.com/embee/sup in the use-mail and > work-in-progress branches. > = > greetings, martin. > = > -- = > eKita - the online platform for your entire academic = life > hackerspace beijing - http://qike.= info > -- = > chief engineer eKit= a.co > pike programmer pike.lysator.liu.se caudium.net societyserver= .org > BLUG secretary beijinglug= .org > foresight developer foresightlinux.org realss= .com > unix sysadmin > Martin B=E4hr working in china http://societyserver.org/m= baehr/ > _______________________________________________ > Sup-devel mailing list > Sup-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-devel _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel