purebred-mua / purebred

A terminal based mail user agent based on notmuch
GNU Affero General Public License v3.0
139 stars 19 forks source link

user documentation #378

Closed teto closed 4 years ago

teto commented 4 years ago

Hi,

I've run purebred and am positively impressed by the UI which combines what I like the most about alot and neomutt. I also liked it worked out of the box with my notmuch config. I was just looking for a way to configure bindings etc ? Should I recompile ? One thing that bothers me is that the UI feels sluggish (1sec/500ms to open a mail in threaded view on a brand new SSD), I have 10Gb of mail indexed by notmuch to give an idea.

romanofski commented 4 years ago

Hi @teto ! Welcome!

The user documentation is still a backlog item for our first release, see #137. Developer documentation would be on hackage, but since there isn't a release yet, it's locally accessible when generated. Due to the user documentation still being a TODO item, you could have a look at our example configuration part of our repository to have a glimpse of what it looks like. I personally have a configuration file here I'm personally using. I think I'm currently the only one who's brave enough using it for sending mail, but I'm not sure if I would go that far as recommending it for productive use. So be aware of that.

Configuring Purebred comes down to using lenses to adjust the default configuration. If you haven't used them before it could be a bit tricky to get used to. Let me know any specific bindings you'd want to change and I'm happy to help. I think it could be useful as a section for the user documentation anyways.

If the configuration changes, starting purebred should recompile the binary. Note this card which is NixOS specific, which means you would need to manually remove ~/.cache/purebred/purebred-* to trigger a recompilation.

In regards of speed, I think your feeling might be right. We've not done any optimizations so far apart from certain obvious ones. @frasertweedale had implemented lazy loading of the thread list, which has the benefit that his gazillions of threads in the index loads in an instant, but causes a bug which is now haunting him #284 ever since.

The load time of a thread causes a write to the database caused by a removal of a tag and the parsing and opening of the mail. Depending of the size of the mail that could have an impact. There is obviously also the rendering of the TUI where we have a potentially known performance problem (see #208). We could optimize writing/tagging but it would be good to figure out why/what is exactly so laggy in order to implement a good solution. If you want to go down that path, I'd recommend filing a separate issue for it with (if available) a reproducer or steps to reproduce the issue.

So to summarize, we're not there just yet for our first release. You will discover a lot of rough edges for a daily productive use. Since we both have family and full time jobs, the hope is that a first release may spark more contributions to speed things along. Otherwise we just keep hacking :)

Anything else, we're happy to answer specific questions or help along any contributions :) The project doesn't have any social media or IRC presence, but you can find both of us on IRC on freenode in #bfpg (UTC+10).

romanofski commented 4 years ago

Dear @teto, I would close this issue since I think we've covered all of your questions. Either we do have already issues filed tracking certain aspects of purebred or we would need more specific information? Is there anything unanswered or missing we're currently not aware off? Cheers!

teto commented 4 years ago

thanks for the lengthy explanation. I would like to contribute to some haskell project and this is the best candidate so far. Right now, i dont have the time but maybe later. Keep the good job !