You are not logged in.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Hmm not much applaus yet. Maybe people are waiting for it to mature. It's definitely interesting. Difficult market though: email is daily business, people are very used to what they use now. But I'm going to monitor this, I feel your dislike of existing clients. It always lacks something of stuff doesn't work or it's too bloated. I used claws-mail for a long time, now thunderbird for a month, can't decide yet to stick to it or not (it has most of what I want, but gtk compatibalilty isn't optimal on dark themes). Luamail may fit.
I know "bloat" is personal, but I'd like to see: 1. optional conversational grouping of mail (threaded); 2. good search options; 3. easy attachment opening, or maybe preview; 4. rss / mailing list usability; 5. tags/stars to mark important stuff; 6. tab completion on contacts in To: entry; 7. notification for new mail of some sort (tray or notification bubble); 8. full gtk usage (no custom widgets/icons), it needs to blend in with other apps; 9. as much inside window as possible, no popups. Not needed: integrated calendar, notes. This is not meant as a wishlist of an impatient nobody, just an indication of what a potential user would like if he were to use luamail. Some of this I already saw being mentioned on your link, so I'm optimistic. Good luck on developing!
Offline
Are there any plans for a CLI component as well? I'd love to be able to use it both locally via GUI and remotely on my server when necessary.
Sounds like a great project!
Scott
Offline
Very nice, I have been planning on starting something similar for a while, with many of the same goals as you have for luamail. One of my ideas was to wrap up notmuch in some libs from luakit. I noticed on your site that searching is still TBD, maybe it is worth checking out?
But anyway, I will be on board once RL dies down, should be in about 2 weeks (first on the list is finishing the adblocker though...).
Offline
Hmm not much applaus yet. Maybe people are waiting for it to mature. It's definitely interesting. Difficult market though: email is daily business, people are very used to what they use now.
So was browsing, and look what uzbl and it's derivatives did.
1. optional conversational grouping of mail (threaded); 2. good search options; 3. easy attachment opening, or maybe preview; 4. rss / mailing list usability; 5. tags/stars to mark important stuff; 6. tab completion on contacts in To: entry; 7. notification for new mail of some sort (tray or notification bubble); 8. full gtk usage (no custom widgets/icons), it needs to blend in with other apps; 9. as much inside window as possible, no popups. Not needed: integrated calendar, notes. This is not meant as a wishlist of an impatient nobody, just an indication of what a potential user would like if he were to use luamail. Some of this I already saw being mentioned on your link, so I'm optimistic. Good luck on developing!
1: yes
2: yes
3: yes
4: yes
5: yes
6: even better: the plan is to implement token matching
7: optional (I would disable by default. popups for new mails are productivity killers)
8: luakit's theming isn't the same as gtk theming. the way statusbar is colored etc is done with color definitons separate from gtk theme. And I like that approach. Also, we do some things like spawning a terminal with vim, when composing a mail.
9: indeed
Are there any plans for a CLI component as well? I'd love to be able to use it both locally via GUI and remotely on my server when necessary.
Sounds like a great project!
Scott
no, the point is that it is a graphical client.
Very nice, I have been planning on starting something similar for a while, with many of the same goals as you have for luamail. One of my ideas was to wrap up notmuch in some libs from luakit. I noticed on your site that searching is still TBD, maybe it is worth checking out?
yes, notmutch uses xapian. that's a possibility. so is lucene or even sqlite text search features, i/we need to compare and test features and performance.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Definitely sounds interesting. I'm pretty happy with mutt and I don't intend to switch away from it, especially after the many hours I spent perfectioning its config. But I'll take a look at luamail! Always nice to see new stuff
Offline
Also, we do some things like spawning a terminal with vim, when composing a mail.
There was some work on getting XEmbed support in luakit, imho gvim in a separate tab would be nicer than spawning a terminal for composing mail. If it is not ready, then luakit.spawn with a callback handler may be a nicer (non-blocking) way of opening an editor.
Offline
Dieter@be wrote:Also, we do some things like spawning a terminal with vim, when composing a mail.
There was some work on getting XEmbed support in luakit, imho gvim in a separate tab would be nicer than spawning a terminal for composing mail. If it is not ready, then luakit.spawn with a callback handler may be a nicer (non-blocking) way of opening an editor.
Hmm, I don't like gvim, because it adds unneeded stuff (like Gtk menubars and whatnot). maybe we can use an Xembed-capable terminal and run vim in there?
embedding gvim/terminal will look a bit nicer than my spawn-new-terminal-window approach, but I don't think it would necessarily be more useful. an argument would be: if it would spawn vim and blocks luakit, it sortof forces you take care of the mail first (i.e. makes you more productive), *but* you can close vim if you _need_ to look at a webpage again, and later return to the message in the same way (do a luamail keybind to continue where you left off).
you can't see the editor at the same time as a misc other tab in luakit, but neither can you with your suggested approach. unless you split off the luamail window into a different window (which is a feature we'll implement at some point), then it works with either approach. but if we block luakit then it won't receive the keybind.
I think you're right, your approach is probably more elegant (if all the issues mentioned in that ticket get resolved), and would allow to do some things properly (like, compose multiple mails at the same time, etc)
it's nice you could do that callback trick. Thanks for showing me. I read somewhere in the luadocs that if you spawn in a non-blocking way, it's not possible to get output and exit code, but that seems solved then with this approach. With this approach it would also allow to compose multiple mails at the same time, but then you should be careful not to close your luakit window if you still have other compose-mail windows open. unless luakit tracks that and warns you.
anyway, your suggested approach of embedding is probably the better way.
edit: interesting, urxvt can be embedded: http://linux.die.net/man/1/urxvt
Btw do you prefer gvim over urxvt+vim ? if so: why?
Last edited by Dieter@be (2011-10-03 14:44:19)
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Btw do you prefer gvim over urxvt+vim ? if so: why?
Mostly for the nicer fonts, colours, underlined spelling and key combinations. I use `set guioptions-=meTr guioptions+=c`; I actually forgot it also has the gtk bits. Nothing major though, I would be happy with either approach.
In my mind I pictured it non-blocking, as I often need to gather information from other mails or quickly respond to something while composing another mail. Embedding each compose window in a separate non-blocking tab (urxvt or gvim, for this argument it doesn't matter) is a nice way of keeping everything separate but still in the same window. Of course it can just as easily be a new luakit window.
you should be careful not to close your luakit window if you still have other compose-mail windows open. unless luakit tracks that and warns you.
The downloads lib does something similar, using the "can-close" signal.
Offline
Nice idea, I would love to have an email client in the spirit of luakit/uzbl and vim. Taking the liberty of answering the question for quigybo as well , I personally prefer gVim over Vim, mainly because of colour schemes. It is only a minor preference though, I tend to use both and like quigybo hide all the gui stuff in gVim.
Offline
Like the idea, having used Opera+M2 for years.
As far as editor goes, don't know how much work it would be, but maybe the/some code from dwb (tiling webbrowser) could be taken, adding some xembeddable terminal/editor and spawn it right under the mail one is answering?
Having that tiling and xembed, one could also add something like cal/calcurse and a plain $editor-session to get something like Outlook - for those who want/need it.
Offline
spawn it right under the mail one is answering?
we could define several keybinds:
with a mail selected, r to reply by xembedding vim/gvim in the current window (thereby closing the first mail) or R to reply by xembedding in a new tab (and keeping the current display as it is).
rendering the original mail above the xembedded vim is probably possible, but complicates things more. it divides your screen space in two, which probably makes the user resize one or the other half, etc. And since the newly mail will start off with a fully quoted version of the first mail, I don't see the point anyway.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
And since the newly mail will start off with a fully quoted version of the first mail, I don't see the point anyway
Personally, I don't like this behaviour. Mails I quote and reply to are usually quite long for me and I find it quicker to just select the interesting parts by hand. But if the configuration is/will be flexible enough to get all this workflows going, I've got no problem having to change default settings.
Can't remember, if it already has been requested, but what I'd really like to have/need is an easy way to call actions on a set of mails, ie. archiving a complete thread in a logical order as .pdf, etc.
Offline
Very nice idea!
Can you tell more about how you plan the gui? Like, how and where are the contents of the mailfolders, the list of mails, shown? how and where the mail itself?
rich_o
Last edited by rich_o (2011-10-04 21:03:15)
Offline
Very nice idea!
Can you tell more about how you plan the gui? Like, how and where are the contents of the mailfolders, the list of mails, shown? how and where the mail itself?rich_o
mailfoders ~ list of mails: in a luakit menu widget at the bottom of the screen.
the mail itself, in the webkitgtk widget.
you can actually see that part working already in the current codebase.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
Thanks.
I did read the source code but because of its early state I wasn't sure if that part is finished or just placeholder code to make it work.
I think I have to try it out some time. Right now, i cannot imagine that an rather small menu widget would work for me and my need for overview. for example, i'm on some rather busy mailing lists and want to be able to see as many of the last threads/mails at once as possible.
rich_o
Last edited by rich_o (2011-10-05 16:34:28)
Offline
Nice. I've actually been thinking about doing the same (only sticking with the Uzbl style) but sadly real life has been cutting down my programming time. Hopefully I'll get around to it but it will be nice to see how your project develops so maybe I don't have to. I'm sick and tired of that monstrosity called Evolution.
Offline
I found out about luakit a few days ago and switched, and I'm absolutely loving it. And I've also been wanting a replacement for claws-mail. So I'm extremely excited to hear about luamail!
It doesn't look like there's been much development activity on luamail in the last month. I hope there is still interest in developing it.
Offline
Thanks.
I did read the source code but because of its early state I wasn't sure if that part is finished or just placeholder code to make it work.
I think I have to try it out some time. Right now, i cannot imagine that an rather small menu widget would work for me and my need for overview. for example, i'm on some rather busy mailing lists and want to be able to see as many of the last threads/mails at once as possible.rich_o
well then? it seems to me our current approach is the direct direction for that.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
It doesn't look like there's been much development activity on luamail in the last month. I hope there is still interest in developing it.
We're just busy people with not much free spare time But of course we are still working on it (albeit very, very slowly)
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline