From eg@gaute.vetsj.com Tue Mar 11 07:38:53 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Tue, 11 Mar 2014 08:38:53 +0100 Subject: [sup-devel] ncursesw 1.4.6 Message-ID: <1394523501-sup-395@qwerzila> Hi, just released ncursesw-ruby 1.4.6. Available at rubygems. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From eg@gaute.vetsj.com Fri Mar 14 08:17:43 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Fri, 14 Mar 2014 09:17:43 +0100 Subject: [sup-devel] ncursesw 1.4.7 released Message-ID: <1394784966-sup-6633@qwerzila> greetings, ncursesw 1.4.7 released: * fix issue #25: include when available for increased portability (fix found by: James Pearson) - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From eg@gaute.vetsj.com Mon Mar 17 07:52:14 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Mon, 17 Mar 2014 08:52:14 +0100 Subject: [sup-devel] [sup] Maildir root: Keep labels in sync with maildir folders (#253) In-Reply-To: References: Message-ID: <1395042468-sup-5821@qwerzila> Excerpts from Matthieu Rakotojaona's message of 2014-03-15 18:53:10 +0100: > Just opened https://github.com/sup-heliotrope/sup/tree/maildir-root > branch at 3f6bc97a14f8e87f1663f924aca5333617cbeec7 (your HEAD) to > track development of maildir-root. I'd like to use it in instead of > `gmail_source` because even if I break my sup, I can still read my > mails with any other MUA in the world. > > --- Reply to this email directly or view it on GitHub: > https://github.com/sup-heliotrope/sup/pull/253#issuecomment-37732781 Cool. Feel free to push fixes there. That was definetly a strong motivation for me as well. - gaute From eg@gaute.vetsj.com Tue Mar 18 14:24:28 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Tue, 18 Mar 2014 15:24:28 +0100 Subject: [sup-devel] deprecating psych migration Message-ID: <1395152363-sup-3117@qwerzila> hi, i just pushed a pull request (#268) which deprecates yaml migration from old 1.8 style configs. the tests for ruby > 2.1 were broken (for the yaml migration bit) and I figured it was futile/not worth it to keep the migration script running for successive rubies. so, as of ruby 2.1.0 it won't be possible to migrate your old config files automatically from pre 0.13 sup. the upgrade path will then either involve using ruby < 2.0.0 to migrate, or to just manually migrate/re-configure sup (which I think is will be the preferred way). currently sup tests pass on 2.0 to 2.1.1 and I am running sup on ruby 2.1.1. seems to work fine. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From eg@gaute.vetsj.com Fri Mar 21 15:00:20 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Fri, 21 Mar 2014 16:00:20 +0100 Subject: [sup-devel] sup 0.16.0 released Message-ID: <1395413618-sup-4468@qwerzila> Greetings, I just released sup 0.16.0, get it at rubygems: $ gem install sup release notes: * sup-sync-back-mbox removed. * safer mime-view attachment file name handling * show thread labels in thread-view-mode * remove lock file if there is no sup alive * deprecate migration script on ruby > 2.1 Cheers, Gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From steven@schmeiser.org Thu Mar 27 23:40:18 2014 From: steven@schmeiser.org (Steven Schmeiser) Date: Thu, 27 Mar 2014 19:40:18 -0400 Subject: [sup-devel] [sup] Maildir root: Keep labels in sync with maildir folders (#253) In-Reply-To: <1395042468-sup-5821@qwerzila> References: <1395042468-sup-5821@qwerzila> Message-ID: <18152441-C2B3-4454-B1E1-3242F62E7412@schmeiser.org> I'm trying out the maildir-root branch, but get the following error: undefined local variable or method `check_enable_experimental' for MaildirSub (deleted):Redwood::MaildirRoot::MaildirSub /usr/local/Cellar/ruby193/1.9.3-p545/lib/ruby/gems/1.9.1/gems/sup-999/lib/sup/maildirroot.rb:153:in `ensure_maildir' I did a diff with an older version of maildir-root that I was using from gauteh's personal repository, but I didn't see anything obviously related to this that changed in maildirroot.rb. Any suggestions? Thanks, steve On Mar 17, 2014, at 3:52, Gaute Hope wrote: > Excerpts from Matthieu Rakotojaona's message of 2014-03-15 18:53:10 +0100: >> Just opened https://github.com/sup-heliotrope/sup/tree/maildir-root >> branch at 3f6bc97a14f8e87f1663f924aca5333617cbeec7 (your HEAD) to >> track development of maildir-root. I'd like to use it in instead of >> `gmail_source` because even if I break my sup, I can still read my >> mails with any other MUA in the world. >> >> --- Reply to this email directly or view it on GitHub: >> https://github.com/sup-heliotrope/sup/pull/253#issuecomment-37732781 > > Cool. Feel free to push fixes there. > > That was definetly a strong motivation for me as well. > > - gaute > > _______________________________________________ > Sup-devel mailing list > Sup-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-devel > From matthieu.rakotojaona@gmail.com Fri Mar 28 07:47:35 2014 From: matthieu.rakotojaona@gmail.com (Matthieu Rakotojaona) Date: Fri, 28 Mar 2014 08:47:35 +0100 Subject: [sup-devel] [sup] Maildir root: Keep labels in sync with maildir folders (#253) In-Reply-To: <18152441-C2B3-4454-B1E1-3242F62E7412@schmeiser.org> References: <1395042468-sup-5821@qwerzila> <18152441-C2B3-4454-B1E1-3242F62E7412@schmeiser.org> Message-ID: <1395992480-sup-9485@kpad> Excerpts from Steven Schmeiser's message of 2014-03-28 00:40:18 +0100: > I'm trying out the maildir-root branch, but get the following error: > > undefined local variable or method `check_enable_experimental' for MaildirSub (deleted):Redwood::MaildirRoot::MaildirSub > /usr/local/Cellar/ruby193/1.9.3-p545/lib/ruby/gems/1.9.1/gems/sup-999/lib/sup/maildirroot.rb:153:in `ensure_maildir' > > I did a diff with an older version of maildir-root that I was using from gauteh's personal repository, but I didn't see anything obviously related to this that changed in maildirroot.rb. Any suggestions? Yes, the `check_enable_experimental` function is defined at the maildirroot level, not the maildirsub level. The whole e8bc811bb9188cbe9c2111b9515110a90278c46e commit is wrong. If you feel adventurous you can fix this: the 2 lines are related to the @maildirroot variable. I'll provide a patch a fix after $dayjob. -- Matthieu Rakotojaona -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 966 bytes Desc: not available URL: From mbaehr@email.archlab.tuwien.ac.at Sun Mar 30 09:51:43 2014 From: mbaehr@email.archlab.tuwien.ac.at (=?utf-8?q?Martin_B=C3=A4hr?=) Date: Sun, 30 Mar 2014 11:51:43 +0200 Subject: [sup-devel] use-mail branch and other work Message-ID: <1396168444-sup-8010@email.archlab.tuwien.ac.at> 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 checking 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 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 searching 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 stable 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 my time 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 match 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 while 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 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 known 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. occasionally, when writing mail i need to look up something in other mails. 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 typing 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 eKita.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?hr working in china http://societyserver.org/mbaehr/ From steven@schmeiser.org Sun Mar 30 20:47:37 2014 From: steven@schmeiser.org (Steven Schmeiser) Date: Sun, 30 Mar 2014 16:47:37 -0400 Subject: [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> Message-ID: <9CF97884-262B-4CAA-951C-D359C331AC3F@schmeiser.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=screen-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?hr 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 checking 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 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 searching > 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 stable 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 my time > 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 match 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 while 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 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 known > 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. > > occasionally, when writing mail i need to look up something in other mails. > 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 typing 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 eKita.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?hr working in china http://societyserver.org/mbaehr/ > _______________________________________________ > Sup-devel mailing list > Sup-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-devel From eg@gaute.vetsj.com Mon Mar 31 12:09:56 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Mon, 31 Mar 2014 14:09:56 +0200 Subject: [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> Message-ID: <1396267373-sup-7639@qwerzila> Excerpts from Martin B?hr'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 for sup. > > first of all, i was very enthusiastic when i discovered sup (i was checking 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 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 searching > 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. 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 stable 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 my 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 match 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 while 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 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 known > 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 other mails. > 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 typing 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 and > 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From eg@gaute.vetsj.com Mon Mar 31 12:02:46 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Mon, 31 Mar 2014 14:02:46 +0200 Subject: [sup-devel] use-mail branch and other work In-Reply-To: <9CF97884-262B-4CAA-951C-D359C331AC3F@schmeiser.org> References: <1396168444-sup-8010@email.archlab.tuwien.ac.at> <9CF97884-262B-4CAA-951C-D359C331AC3F@schmeiser.org> Message-ID: <1396267296-sup-756@qwerzila> Excerpts from Steven Schmeiser's message of 2014-03-30 22:47:37 +0200: > 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. I added an option in #283 as a response to your old request in #118. Please try it out. Probably needs some testing in regular mode first as well.. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From matthieu.rakotojaona@gmail.com Mon Mar 31 19:42:57 2014 From: matthieu.rakotojaona@gmail.com (Matthieu Rakotojaona) Date: Mon, 31 Mar 2014 21:42:57 +0200 Subject: [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> Message-ID: <1396294116-sup-6519@kpad> Hello Martin! Excerpts from Martin B?hr's message of 2014-03-30 11:51:43 +0200: > 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 searching > 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. Isn't that more ore less achievable with the inbox label ? It is added automatically to new messages unless you explicitely specify otherwise. > use the use-mail branch and fix problems as i discover them. > i stumbled into this by accident. i tried use-mail because current stable 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 my time > is better spent fixing my problems here, and avoid RMail alltogether. Good :) > some ideas: > i'd like the ability to apply a label change to all messages that match 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. Semi-answer: bin/sup-tweak-labels is this, except it's supposed to be used from the command line. Moreover you must exit sup because the index can't be shared safely. Since Sup is mostly targeted towards the ui and that use case happen once in the lifetime of a user (hopefully !), I guess I'm ok with how things are. I don't know how we could manage to reproduce the bin/sup-tweak-labels _inside_ sup efficiently, but I'm open to the discussion. > i am using procmail still to prefilter mail. it's going to take a while 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 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 known > 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. That would be possible with a hook, possibly in PollManager::do_poll > occasionally, when writing mail i need to look up something in other mails. > 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 typing 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 do have interesting ideas. Welcome on board :) > 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 -- Matthieu Rakotojaona -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 966 bytes Desc: not available URL: From eg@gaute.vetsj.com Mon Mar 31 20:57:06 2014 From: eg@gaute.vetsj.com (Gaute Hope) Date: Mon, 31 Mar 2014 22:57:06 +0200 Subject: [sup-devel] use-mail branch and other work In-Reply-To: <1396294116-sup-6519@kpad> References: <1396168444-sup-8010@email.archlab.tuwien.ac.at> <1396294116-sup-6519@kpad> Message-ID: <1396299131-sup-5113@qwerzila> Excerpts from Matthieu Rakotojaona's message of 2014-03-31 21:42:57 +0200: > Excerpts from Martin B?hr's message of 2014-03-30 11:51:43 +0200: > > some ideas: > > i'd like the ability to apply a label change to all messages that match 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. > > Semi-answer: bin/sup-tweak-labels is this, except it's supposed to be > used from the command line. Moreover you must exit sup because the index > can't be shared safely. > Since Sup is mostly targeted towards the ui and that use case happen > once in the lifetime of a user (hopefully !), I guess I'm ok with how > things are. I don't know how we could manage to reproduce the > bin/sup-tweak-labels _inside_ sup efficiently, but I'm open to the > discussion. We could do something similar to what tagging and + does now, but iterate over all the threads in the search without rendering them. Unless the chunks are loaded it is a matter of loading it from the index. It would be an extension to thread-index mode. Basically a command: Apply an action to all threads matching the current search. It will be the equivalent of: Search + show all (!!) + tag all + do action. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: