[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sup-devel] use-mail branch and other work



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/