I converted the PR as draft. Thanks for the initiative!

Status

At the moment it looks like this, when running himalaya tui:

Note

I have a suggestion for the run() funtion in src/main:

1. Should we rather create an extra function which reads the config information
   of the config.toml file? Because I'm thinking of giving the user the
   possibility to reload the config anytime if the TUI is enabled.

2. A little rewrite of the matching part. I wrote my suggestion in the src/main.rs
   file. You can find by searching the word SUGGESTION in it.

https://github.com/TornaxO7/himalaya/projects/1

So I created the project here, if you want to see the process.

1. Should we rather create an extra function which reads the config information
   of the config.toml file? Because I'm thinking of giving the user the
   possibility to reload the config anytime if the TUI is enabled.

It could be related to #156. I planned to implement a daemon that keep in memory the login process. I think it could be the right place to reevaluate the config.

2. A little rewrite of the matching part. I wrote my suggestion in the src/main.rs
   file. You can find by searching the word SUGGESTION in it.

A refactor of msg matching args has already been proposed and merged, you can check it for inspiration #151

@soywod

Question

What do you think about enabling a second config file called tui.toml? Because I see that there will be many ways to configure it starting from the look of the borders and colors until the customizable keybindings.

What is preventing the fact to put new TUI options inside the existing one ? They could be attach to a new category, or prefixed with tui-. Those options could be also defined as feature !

I thought that it this section than might be too big, but yeah.... I guess you're right.

By the way, congratulations for > 1.000 stars on github for himalaya :)

Question

I'm a little bit unsure what to do with the attributes of the mailboxes:

Do we need to display them?

It is a good question. I guess it can be put aside for now, we will see later 😉

Question

Since I'll add a new part to the Config, should I split up the src/config/model.rs into it's different structs? Like

src/config/
    account.rs
    config.rs
    tui.rs

? What do you think about that? From my point of view, this makes it clearer, where to find what.

Question

In your src/config/model.rs you have this macro:

    #[serde(flatten)]
    pub accounts: HashMap<String, Account>,

How does this work? I can't find it, if I search the term flatten in its doc.

I'm interested in your opinion of my latest commit with the three new sections for the config.toml file. Do you think that's ok, if the users have to add this to their config?

[tui]
[tui.sidebar]
[tui.mail_list]

?

Question

How should we let the user add his own keybindings?
I thought something like that:

[tui]
keybindings = {
    q = "quit"
}

Do you have a better idea?

@TornaxO7 do you mind if I recreate a branch for the TUI (starting from development on my repo) and integrate piece by piece what you already done? I tried to merge development into your branch but the code base changed so much, it just does not fit any more. Especially the backend part: your branch is still tied up to the old ImapConnector.

Wait, you're thinking that the backend is already ready for the TUI?

Don't worry, I think that I'll have to start from the biginning anyhow, since the code changed that much. We can even close this PR at the moment.

Wait, you're thinking that the backend is already ready for the TUI?

Implementations may (will) need some adjustments but the trait is solid enough to be used.

Don't worry, I think that I'll have to start from the biginning anyhow, since the code changed that much. We can even close this PR at the moment.

I also think it's gonna be easier this way. But I thought you were not so available, that's why I started to take back this feature. Do you feel like doing it? Anyway, I already pushed sth on the tui branch. All the args and handlers system is set up and plugged to the main.rs. Now, the work left is to integrate all what you wrote so far, and change the ImapConnector by Box<&mut Backend>.

Implementations may (will) need some adjustments but the trait is solid enough to be used.

I'd still wait for some features. Especially for the caching! Because during the time, when I was still doing this, the fetching time was horrible. Everytime when you want to look the content of your mail, you'd have to wait about a second to be able to read it.

I also think it's gonna be easier this way.

Then you can close it you want or I'll do it tomorrow.

But I thought you were not so available, that's why I started to take back this feature.

What do you mean with this?

Do you feel like doing it?

Not yet, I'm in the exam-session at the moment. Tomorrow is my first one (one of 3 if you exclude programming) yaaaaaaaay ._. Also I need some to do the wizard first.

Now, the work left is to integrate all what you wrote so far, and change the ImapConnector by Box<&mut Backend>.

Hm... I think that restarting won't hurt that much and as far as I remember correctly, I didn't do that much, otherwise I can look a little bit back to the old code and adjust it.

I'd still wait for some features. Especially for the caching!

I will not implement a cache system for those (well thought) reasons:

• Himalaya is not an offline solution to read your emails. It is just a command line interface over your emails, using different backends. The IMAP backend relies on the network, so it is normal to have some delay.
• A cache system does not make sense on a CLI. When you run himalaya list you always want to have an up to date list, you never have a chance to use your cache.
• If you are looking for offline, you need to synchronize your emails locally in a Maildir (see mbysnc and offlineimap). Since Himalaya supports the Maildir format, you can interact directly with it instead of your IMAP server.

That said, the TUI has different requirements. To have the best UX (in my opinion), a TUI should work offline (a bit like a GUI, think Thunderbird), and it should work out of the box (or with toggle feature). This last statement is not compatible with asking users to install and configure on their own mbsync or offlineimap. And none of them propose a lib. The only solution I see for now is to develop a Rust lib (and a CLI?) that synchronizes remote IMAP/POP servers with a local Maildir. This way the Himalaya's TUI could rely on it and offer offline to its users!

What do you mean with this?

I just refer to what you said in the TUI issue #24 (comment):

If anyone has more time and motivation (I don't mean it in a bad way) than me, then you can create your own fork and implement the TUI because at the moment I'm pretty much exhausted by my university and I'd like to complete my eduacational project first... and... sadly the code in my fork isn't up to date anymore...

I will not implement a cache system for those (well thought) reasons: (...)

Hm... I understand your arguments. Welp, it sounds reasonable to avoid making himalaya a cli-tool "frontend" with a lot of backend (like downloading mails) stuff.

To have the best UX (in my opinion), a TUI should work offline (a bit like a GUI, think Thunderbird), and it should work out of the box (or with toggle feature).

Yeah, I agree here.

And none of them propose a lib. The only solution I see for now is to develop a Rust lib (and a CLI?) that synchronizes remote IMAP/POP servers with a local Maildir. This way the Himalaya's TUI could rely on it and offer offline to its users!

Pew, that's not gonna be a "little" project I guess...

Anyway, I'm agreeing here to only provide the TUI as "another" frontend for himalaya.

But before starting to implement the TUI, I'd like to collect some ideas first, how it should look like and what functionalities it should provide. This would help me to structure it and avoids reimplementing stuff.

Pew, that's not gonna be a "little" project I guess...

Well, in fact I will reuse many parts from Himalaya, it should not be that long! Here the repo https://github.com/soywod/everest.

But before starting to implement the TUI, I'd like to collect some ideas first, how it should look like and what functionalities it should provide. This would help me to structure it and avoids reimplementing stuff.

It is a good idea! A good start would be to test the vim and/or the emacs plugin. I could also try to list a bit the common features that a frontend should implement.

I could also try to list a bit the common features that a frontend should implement.

Aye! Something like this would be helpful! I created a discussion for this, since I think that it suits here for our needs(?).