[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/