From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost ([128.39.46.106]) by mx.google.com with ESMTPSA id x45sm32639800eeu.23.2014.03.31.05.11.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Mar 2014 05:11:05 -0700 (PDT) From: Gaute Hope To: sup-devel Subject: Re: [sup-devel] use-mail branch and other work In-reply-to: <1396168444-sup-8010@email.archlab.tuwien.ac.at> References: <1396168444-sup-8010@email.archlab.tuwien.ac.at> Date: Mon, 31 Mar 2014 14:09:56 +0200 Message-Id: <1396267373-sup-7639@qwerzila> User-Agent: Sup/git Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; boundary="=-1396267796-677691-12301-7785-2-=" --=-1396267796-677691-12301-7785-2-= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Excerpts from Martin B=C3=A4hr's message of 2014-03-30 11:51:43 +0200: > hi, > > i'd like to introduce what i am working on and some ideas that i have f= or sup. > > first of all, i was very enthusiastic when i discovered sup (i was chec= king out > a fork of mutt, which was including notmuch, which was inspired by sup.= the > 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 = have > 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= the > 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 witho= ut > reading the message or marking it as read. this distinction is import= ant > because i have lots of old unread mail, and so i can't see where i ha= ve > actual new mail. > i don't want to mark everything as read because occasionally i am sea= rching > for an old message where i read about something specific, which is ha= rd 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. Perhaps you followed the discussion with Ico / Zevv on irc? There might be a solution together with the proposed hooks in #276, or are you looking for something more integrated? > > use the use-mail branch and fix problems as i discover them. > i stumbled into this by accident. i tried use-mail because current st= able and > develop branches have problems on debian 6. as a result i discovered = that 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 m= y time > is better spent fixing my problems here, and avoid RMail alltogether.= Excellent! > > some ideas: > i'd like the ability to apply a label change to all messages that m= atch a > given search, not just the ones loaded into the buffer. > > i have imported a lot of uncategorized messages from my mutt inbox, a= nd i > want to make use of sup's tagging to group them. instead of loading a= ll > messages in a search with !! it would be nice to just let sup tagg th= ose > messages in the background. > > i am using procmail still to prefilter mail. it's going to take a w= hile 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 automaticall= y tagged > 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 kno= wn > non-spam message is also not spam, and should thus not apply the spam= label > to this message. > > the same goes for any message from an email address that i have sent = mail to. > iaw, all my contacts should automatically be whitelisted. Some of these might be harder to do with sup since we don't keep an adress book. One option is to keep updating it as mail happens, but also have a way to run through the index and generate the stats you need. > occasionally, when writing mail i need to look up something in othe= r mails. > with mutt i "solved" this by running two instances of mutt in paralle= l. (the > main reason for that was to be able to switch between the inbox and o= ther > folders without having to reload the inbox all the time. sup solves t= hat 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 anoth= er > 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 ty= ping the > name in the search prompt. You can presse enter after searching to get a list, but I agree, it could be a streamlined way to do these things. > 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 an= d > work-in-progress branches. Lots of good ideas and I hope that you can get sup to do what you want. I think much of it could be included if it needs to be tweaked. This is great, if you are interested I could set you up as an contributor on the github organization and you could push your changes to the use-mail branch. With your changes and especially if we get crypto working on Mail I would switch completely as well. - gaute --=-1396267796-677691-12301-7785-2-= Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTOVsUAAoJEJgnp+igdJAjv1sP+wf73htahrMgUStWJIQQW9K2 9VVDVeIsoW4OBRECdDSm9XQLvGEqT6XH2Wp+YHhsWHP81mBT9LdjgZ+Y0J0defye QTXuukBSMo3GCp0NPjC723B9n3j78vY6jMOYlxQkGm0AMwVjZs2Ei1lxRuFF+pAa BcXEkpH+jkQLR82O7LXwtDqtKzo4ETMIFejDshSNXjNt1gmm/sWLIUnDzSKWVtAe mBpqpsO1E/XrxAsddQNlA6UczsIgEFDxQxb7lHPbknNnFP+l6xWwaiyFhBVGCvoG TBI9dluUe+WyYKY/P5J+i4CpW/O3SCdbJReh6gmF0XVZaOES3wQdi4voE2tOaj30 uA//YE1UALycEPzMjQkKfiqIHM9im/L73rOlvI40RueuF4l9oDQeIEZvfJnGJ6Zp qtSDSpVGRCodIefe8OTjDvlb1b3slRtgfLxjbf7Cdz7lIsiFDf8cp+VtB2SGri9h /vx3lse093BJs3HrowL/+h/wrh0JxJgRPacQBAZ+CspS/Cl7FPgJuv4qnf4ulEWY OXWEE029W3fD+m6KgogaH5rkMiFjv3znlduu4fFQEBFn51BAuwcfv+YlaAPlrMBb ABM/TEWIUGsz23JNnxJdVxOUwNZa1Epz2e8LZUyJq5XKY9sZTXhvXyBY2jJ+DRU7 n3Rq8UVHLdSRkOxJ8Uq4 =y++s -----END PGP SIGNATURE----- --=-1396267796-677691-12301-7785-2-=--