Archive of RubyForge sup-devel mailing list
 help / color / mirror / Atom feed
* [sup-devel] use-mail branch and other work
@ 2014-03-30  9:51 Martin Bähr
  2014-03-30 20:47 ` Steven Schmeiser
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Martin Bähr @ 2014-03-30  9:51 UTC (permalink / raw)
  To: sup-devel

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@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-30  9:51 [sup-devel] use-mail branch and other work Martin Bähr
@ 2014-03-30 20:47 ` Steven Schmeiser
  2014-03-31 12:02   ` Gaute Hope
  2014-03-31 12:09 ` Gaute Hope
  2014-03-31 19:42 ` Matthieu Rakotojaona
  2 siblings, 1 reply; 9+ messages in thread
From: Steven Schmeiser @ 2014-03-30 20:47 UTC (permalink / raw)
  To: Sup developer discussion

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 <mbaehr@email.archlab.tuwien.ac.at> 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@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-devel

_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-30 20:47 ` Steven Schmeiser
@ 2014-03-31 12:02   ` Gaute Hope
  0 siblings, 0 replies; 9+ messages in thread
From: Gaute Hope @ 2014-03-31 12:02 UTC (permalink / raw)
  To: sup-devel

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-30  9:51 [sup-devel] use-mail branch and other work Martin Bähr
  2014-03-30 20:47 ` Steven Schmeiser
@ 2014-03-31 12:09 ` Gaute Hope
  2014-04-01  4:13   ` Martin Bähr
  2014-03-31 19:42 ` Matthieu Rakotojaona
  2 siblings, 1 reply; 9+ messages in thread
From: Gaute Hope @ 2014-03-31 12:09 UTC (permalink / raw)
  To: sup-devel

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

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-30  9:51 [sup-devel] use-mail branch and other work Martin Bähr
  2014-03-30 20:47 ` Steven Schmeiser
  2014-03-31 12:09 ` Gaute Hope
@ 2014-03-31 19:42 ` Matthieu Rakotojaona
  2014-03-31 20:57   ` Gaute Hope
  2014-04-01  3:46   ` Martin Bähr
  2 siblings, 2 replies; 9+ messages in thread
From: Matthieu Rakotojaona @ 2014-03-31 19:42 UTC (permalink / raw)
  To: sup-devel


[-- Attachment #1.1: Type: text/plain, Size: 4474 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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

_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-31 19:42 ` Matthieu Rakotojaona
@ 2014-03-31 20:57   ` Gaute Hope
  2014-04-01  3:55     ` Martin Bähr
  2014-04-01  3:46   ` Martin Bähr
  1 sibling, 1 reply; 9+ messages in thread
From: Gaute Hope @ 2014-03-31 20:57 UTC (permalink / raw)
  To: sup-devel

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-31 19:42 ` Matthieu Rakotojaona
  2014-03-31 20:57   ` Gaute Hope
@ 2014-04-01  3:46   ` Martin Bähr
  1 sibling, 0 replies; 9+ messages in thread
From: Martin Bähr @ 2014-04-01  3:46 UTC (permalink / raw)
  To: Matthieu Rakotojaona; +Cc: sup-devel

Excerpts from Matthieu Rakotojaona's message of 2014-03-31 21:42:57 +0200:
> > 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.
> Isn't that more ore less achievable with the inbox label ? It is added
> automatically to new messages unless you explicitely specify otherwise.

the inbox is where all the important new mail comes in. it is easy to reach
with "I", which is important. i do not want mailing list emails in the inbox. i
have some very active lists, which would just flodd the inbox view and drown
out all other new messages.

i could use the inbox if i made a search that excludes all mailinglists, but
that search would take more than one keystroke to reach. and it would not give me other features, such as a count of new messages in the label-list

"new" is a state that should be automatically cleared when i read a message or
when the message/thread goes out of view.

i currently have it working semi-automaticly in 
https://github.com/eMBee/sup/commit/9debc5be804f6dc38cc9d4a14d5eead0337b1e22

the new state is cleared when a thread is read or when i refresh with @

in the label-list-mode, labels are sorted by the time of the latest new
message, and each label has a count of how many new messages this label has:

                 new    429 messages,    260 unread, 429 new -     5:21am                         
              Unread 614916 messages, 614916 unread, 260 new -     5:21am                         
               Inbox 928373 messages, 562870 unread,   9 new -     5:18am                         
                news  91638 messages,  55560 unread,  74 new -     5:03am                         
                fish   4037 messages,   2447 unread,   5 new -     3:33am                         
                Spam  18456 messages,  11190 unread,  43 new -     3:26am                         
                 git  55779 messages,  33819 unread, 100 new -     2:53am                         
             Replied     77 messages,      0 unread,   0 new -     2:08am                         
                 sup   6401 messages,   3880 unread,   0 new -     Mar 31                         
          Attachment  14521 messages,   8804 unread,   8 new -     Mar 31                         
              debian  13541 messages,   8210 unread,  10 new -     Mar 31                         
              fedora    221 messages,     89 unread,  14 new -     Mar 31                         

i can now easily see where there are new messages, how recent they are, and how many.

> > 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.
> 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.

ah, thanks, yes, that should solve this problem mostly.

> 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'd be happy for it to not be efficient. just some fire-and-forget command that
silently chuggs away in the background.

> You do have interesting ideas. Welcome on board :)

thank you. 
 
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@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-31 20:57   ` Gaute Hope
@ 2014-04-01  3:55     ` Martin Bähr
  0 siblings, 0 replies; 9+ messages in thread
From: Martin Bähr @ 2014-04-01  3:55 UTC (permalink / raw)
  To: Gaute Hope; +Cc: sup-devel

Excerpts from Gaute Hope's message of 2014-03-31 22:57:06 +0200:
> 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.

yes, that's how i imagined to use it.

btw: do action for all tagged blocks. with a few threads tagged or on a fast
machine it's not noticable, but on a slower machine it is.

if the above is solved to run in the background, then the current do action for
all tagged, could use the same mechanism. it is just a matter of which list of
threads/messages the function receives to operate on:

search + tag some messages + do action on tagged -> call action with list of tagged messages.
search + do action on search -> call action with list of matching messages.

same function for both, return to view immideately, maybe update view when function completes

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/


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [sup-devel] use-mail branch and other work
  2014-03-31 12:09 ` Gaute Hope
@ 2014-04-01  4:13   ` Martin Bähr
  0 siblings, 0 replies; 9+ messages in thread
From: Martin Bähr @ 2014-04-01  4:13 UTC (permalink / raw)
  To: Gaute Hope; +Cc: sup-devel

Excerpts from Gaute Hope's message of 2014-03-31 14:09:56 +0200:
> > add support for a "new" state that is different from unread.

> 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?

new state operates on the thread-index.
a message is new if it has not been seen in an index.

if i have read the cubject-line and decided that i don't want to read this
thread, then at that point it is no longer new. (of course if i do read it, it
is also no longer new)

i have this mostly working in
https://github.com/eMBee/sup/commit/9debc5be804f6dc38cc9d4a14d5eead0337b1e22

since we don't have a ruby mind-reader gem, i am currently using @ refresh to
clear the new state. other options could be to detect when the cursor is
scrolled over a message, or when the buffer is closed or hidden when i switch
to another buffer.

initially i cleared the new state when the thread-index was loaded, but that
meant i could not see what was actually new, so i switched it to refresh.

> Some of these might be harder to do with sup since we don't keep an
> adress book.

for another idea that i have in mind, this is something i'd like to change.

> >     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.

that's what i do now, i hardwired \+enter as the key-sequence to get the list.
but it means i have to deal with two lists, which is not wrong, but a merged
list would be nice as a 3rd option.

> 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.

let me work on my own repo for a while, as i am quite new to ruby, learning it
as i go along, so i don't feel confident to make commits without anyone
reviewing them. (actually, i think, if at all possible any commit to a project
should be reviewed by at least one other person)

but thanks for the offer. i am sure in time we'll see
whether my work is good enough.

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/


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-04-01  4:13 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-30  9:51 [sup-devel] use-mail branch and other work Martin Bähr
2014-03-30 20:47 ` Steven Schmeiser
2014-03-31 12:02   ` Gaute Hope
2014-03-31 12:09 ` Gaute Hope
2014-04-01  4:13   ` Martin Bähr
2014-03-31 19:42 ` Matthieu Rakotojaona
2014-03-31 20:57   ` Gaute Hope
2014-04-01  3:55     ` Martin Bähr
2014-04-01  3:46   ` Martin Bähr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox