Purebred allows to create and send plain text e-mails (see issue #13). What we need tho is a way to compose multipart e-mails. The basics are there, and mime-mail already provides an interface for creating them.

With the implementation to automatically set mails as "read" I ran into one case in which I had a hard time properly propagating the error up to the application out of function with IO. Consider cleaning this up by using the MonadError transformer.

For the discussion see #56

With the current email parser in use, mime, mails seem to not be correctly displayed and resulting in artifacts like: don�t
Everything encoded as us-ascii seems to be fine.

When viewing an email it'll be cool to fold all quoted items in an email (or maybe x nested amount of quotes)

When entering notmuch search terms, it would help the user a lot to autocomplete search terms. For example:

• on an empty input, you can cycle through possible SearchTerm constructors with a tab (from hs-notmuch)
• if you start with a letter matching one of the constructors, it automatically fills it out placing the cursor after the ':', a backspace deletes the entire prefix.

Can't think of anything else atm.

Some issues had hinted on it, but we want to support this somehow. Not sure how an architecture would look like, but at least I think we need the item.

Before going back to coding, I think it'll be wise to spend a bit of time designing the UI. I'd like to write some design docs and maybe personas or user scenarios to make discussing present/future UI improvements easier.

Given githubs proprietary nature, maybe consider using some of the alternatives like pagure or gitlab?

A search which yields a large result takes quite a long time. I've profiled a bit and here are the stats:

Mail indexed in notmuch: 170297
notmuch search: *

• neomutt: 18s
• purebred: 32s
• alot: 1s (not even)

purebred.txt

So I have been thinking how to test the application, because already with its basic set of capabilities it's getting painful.

There are certain aspects which can easily be tested (e.g. parsing mails don't crash with certain inputs etc), but there is currently no way I can think of to test the app.

I've studied the brick types, but my understanding is limited. From what I understand at this point, due to the fact that some data types are internal, there is currently no way to test any event handling or state changes in the EventM monad.

I've played around a little bit with screen and tmux and there is a possibility to use a terminal multiplexer to run in a detached screen session, while sending keys to the application. Afterwards we can make a screen dump and use that for assertions. That seems to me currently the best option to do black box testing (and perhaps the only way to full test the overall application). Although it seems very heavy handed.

I might spend a bit of time understanding how the whole rendering works in a terminal application. Perhaps there is an easier way to emulate a dummy console and make assertions against it ...

Signing and encrypting is important. I'm just not clear if it should be in the 1.0 release or not.

We should sanity-check the configuration before launching into the program.

Happy to leave this for someone else for now (maybe do some recruiting at BFPG?).
For now let's just make a list of the things to check.

• database can be opened (since 5240c08 purebred terminates on startup if it can't open the database)
• initial notmuch search term does not return an insane amount of mail (obviated by #233)
• keybindings are non-empty ?
• #212 (deepseq the config value)

I've implemented a proof-of-concept feature to manipulate the search terms. So for a 1.0 I guess this could be almost ticked off. Yet for a free form field I think it will have to be tested by a few other people in order to provide this as a baseline feature.

For the future I think we can do better. For example:

• validating user input based and color coding the validity
• search term completion

maybe more. But lets track the improvement in a separate issue.

At this point Keybindings are configured as a flat list in each view in separate configuration slots. Configuring different Keybindings turns out to be tricky, since the user:

• needs to import all Keybindings for the specific view he wants to change the bindings for
• needs to know the list operations to merge his Keybindings with the ones which come as default

The problem with that approach is, if you stuff the merging of your and the default key bindings, you end up with the default keybindings which are not necessarily the ones you know (yes there should be a view which shows all of them, but that's a separate issue).

Since we're already recording which view has the focus, I'm thinking instead of configuring the key bindings as a list for each view, why not configure the bindings as one tree.

• each branch is basically the focus of the current view
• it will allow to traverse up (e.g. composing a mail, back to the index view)
• it will allow to easier "merge" the users with the default bindings
• it should significantly make it easier to look up key bindings

So I can think of a lot of benefits with the new approach, but no real draw backs come to my mind at the moment. Perhaps it's not as peachy as I envision it...

At the moment I've included a special testing key binding the index key bindings which connects to the socket setup by TestUserAcceptance.hs. Those keybindings shouldn't be present in a "production-ready" application.

Not sure if that really needs an issue since it feels so basic.

This might be not something for a client, but rather for notmuch as a patch itself. But I thought we better track it.

The corresponding notmuch feature request is here: https://www.mail-archive.com/[email protected]/msg44527.html

It should be possible to order by various fields including: date, from, received, subject, size, tags. I took what mutt currently allows. Never really used most of these, so perhaps starting poing might be: date (ascending/desceding) for 1.0 and anything else implement upon need.

I use tagging to perform actions on multiple mails every day.

Now with write support in hs-notmuch, adding a way to reflect that mail has been viewed is possible. We could just easily remove the "unread" tag, write the rest of the tags to notmuch and be done with it when you view the mail.
Also add a keybinding which sets the mail back to "unread".

We need a test which covers the use of a configuration file. Since we settled on a XMonad style config, the test needs to run a customized config with the purebred lib installed. I'm currently not sure how this will work with stack (perhaps not as a user would if a distro package would be installed), but I guess that's something to figure out.

With the use of custom configurations implemented in #8 it should be possible to provide theme support by manipulating the attribute map.

At this point in time this feature is very vague in my understanding. Wishful thinking: I can undo whatever actions I've applied on my mails (except actions like sending ... ).

For example if I have tagged messages wrong, how can I find the wrong tagged mail again?

Microlens docs say:

don't use this library if: You need Isos, Prisms, indexed traversals, or actually anything else which isn't defined here

We need those things. Therefore depend on lens.

If we stick with brick, microlens will be a transitive dependency. Oh well.

Currently the user needs to explicitly point purebred to the notmuch database, e.g.::

purebred --database ~/Maildir

This is cumbersome. I've already configured notmuch with a path to the database. Purebred should parse the notmuch config and use the filepath configured in there.

I currently have a game on the way to show new mail. I suppose the classic Maildir statuses should not be used anymore, but rather everything driven by tags. I wonder if the user designates a tag reflecting "new", "read" etc or if there are other things to consider.

Programs using hs-notmuch can misbehave due to file descriptor leaks
(EMFILE).

Forcing major GC via System.Mem.performMajorGC at regular intervals avoids
the issue, so technically there is no leak - the things that could be getting cleaned
up are unreachable. But for some reason they are not getting cleaned up
soon enough and enough FDs are "leaking" to cause problems.

Ideally the problem should be resolved in hs-notmuch, though at this stage I have no
idea how.

If a workaround is truly required, we can monitor the number of open FDs
and force a major GC when it approaches the limit for the process. (Yes, horrible!)

From the perspective of hs-notmuch, there is no way to absolutely avoid this because
it depends what the program does with the messages.

I think it would be good to provide visual feedback when entering search terms to color code them indicating if search terms bogus.

Currently the list only shows from and the subject, but no tags. It should show tags as well.

PS: I think in the future that should be configurable what to show, but I guess there is nothing wrong by showing tags by default. I guess if you add a lot of tags that can be a problem, but lets cover that in a separate item.

In mutt it was always a pain if you needed to lookup details for a mail you're replying.

The workarounds ranged from either starting a new instance to lookup important details or postpone the mail, lookup the detail and continue.

Alternatively, when replying you should have access to the details of the mail you're replying to.

During composition of a new e-mail, we'll need a small parser which:

a) produces an address
b) can be used to provide feedback for the user if an invalid (as syntactically invalid) e-mail is entered

Managing attachments during composing as well as reading is important:

Composing:
*On few occasions I think I had to adjust the mime type

Viewing:

• Saving attachments
• Piping attachments through external programs
• Printing individual attachments

When the initial search term returns a large number of messages,
purebred crunches away at it. The UI does not get drawn and after
a few seconds the program crashes with message:

custom.hs: setupTerm: Couldn't look up terminfo entry "xterm-256color"

We need support for mappings between a key press and a action. This should include redefining how to quit the program.

We need to choose a license for purebred

After manipulating the notmuch search in purebred, the focus should automatically go back to the mail index. At this point the user acceptance test codifies an additional Escape key press to change the focus back to the mail index. That should not be necessary. That means:

• remove the additional Escape keypress from the UAT
• fix the code to automatically refocus the list of mails

When viewing an e-mail, it should be possible to see all headers of the e-mail. That will help with picking header fields to filter on as implemented in #25 .

I would like 7.10 as minimum (pre-AMP GHC is dead to me).

@romanofski if you're cool with that, let's put it in the readme or something to formalise the decision.

We are not using this config. When we invoke the editor to inspect EDITOR env var,
and default to vi explicitly at that point.

This may be another case of "default config is an IO a"...

The default action SHOULD use whatever is in EDITOR if set, otherwise use vi.

Thinking more about this it is a nice idea to have IO FilePath for this config too.
Use case: a user wants a single purebred config to work on different hosts, and the
config uses aspects of the environment to work out what to invoke. For example if
we end up supporting Windows, the action could inspect the platform / environment /
see what's installed and select the editor accordingly.

We discuss requirements and options for MIME parsing at #19.

But we also need to parse RFC (2)822 messages, where most of the headers life.
Conceptually, the type is ([Header], Body).

But note https://tools.ietf.org/html/rfc5322#page-21 ; some headers must appear
exactly once, zero or 1 times, or 0 or more times, and some headers have special
formatting. We should expose this structure with optics (whether or not
the underlying representation has this structure).

IMO we should make a strict implementation of the standard, then parse
a lot of mail to find any counterexamples. If it's a true counterexample and
not a bug in the parser, I'd like to NOT relax the parser implementation; instead,
we could implement "repairer functions" for working around common deficiencies.

Although if e.g. gmail produces non-conformant messages, well, maybe that will
be a case to relax the parser.

We need a way to store and retrieve addresses. This might also be something which could go into a plugin, while the most basic form could be simply parsed from a file similar to what mutt does.

Thinking of it, it would be nice if there are multiple forms addresses can be looked up. Just because you might keep some addresses local, but have access to an ldap server.

Issue #27 added keybinding support, but users can not customize those. This item is for adding support to overwrite the default keybindings from a configuration file.

This can not be worked on before we've added configuration support tracked in Issue #8

There is a little bug in purebred, which is editing the notmuch search. At this point the user always needs to explicitly move the cursor to the end in order to either remove everything or extend the query. That's frustrating and poor UX.

While playing around, I've realised that viewing e-mails needs good support for a mime parsing library. Googling around seems to suggest that: https://hackage.haskell.org/package/mime is the one which might work well to parse mime contents. Any other suggestions?

This touches a little bit on the architecture as well, but I wonder how users should be able to configure the tool. Do we use a high level language like YAML or to make it easy to configure? There are some benefits from using e.g. Haskell as well, although it is less portable in the sense if you'd use configuration management you wouldn't easily able to template it.

Being an XMonad user, there seems to be quite a big benefit at how XMonad is architected. Your config which you compile pulls in core and plugins. That is very flexible from writing plugins by a community, although not very end-user friendly who don't want to get into the Haskell details...

I would leaning almost not to put too much weight on end-user friendliness, but think of it as a professional who would be smart enough to pick up some Haskell to configure his tool.

More a wishlist item or perhaps something for an external program.

Sometimes it would be really cool if the client could produce a summary. We have a database of mail. There should be a possiblity to produce a similar thing to what the summarize not can do on Reddit.

A list of recently performed search patterns could be very useful. This can be transformed into a little editor and/or if maybe sorted on recently used serves as an easy way to perform common searches without too much fuzz...

When viewing e-mails, it should be configurable which headers are shown by default.

That's a bit of a *doh item, but very important to make it useful.

Apart from changing the order of the list of mails, which should be mostly straight forward, showing threads will be a bit trickier since it needs some additional information for drawing.

I'm wondering if the sorting order (including showing threads) needs a special data type to make this easier "configurable".