Meli email client, pre-alpha release | Hacker News Reader

Meli email client, pre-alpha release

meli.delivery

192 pointsUkiahSmith133 comments

With all respect for the hard work done on this client, but is it just me or is the TUI getting too much attention recently??

I think the GUI stacks are too bloated or too hideous (electron, cpp/qt,c# and it's limitations, etc...) to work with these days so much that the cool kids (hardcore techy people) just gave up and started doing TUIs to solve their own problems directly?

I think you've hit the nail on the head, I've thought about this as well. I think it's clear that UI's are a problem yet to be solved, which is why Electron took off. If you've got a website, you've got a GUI with Electron, and a looot of people know how to slap together some JS and HTML.

I would love to see a language agnostic UI stack that can run across platforms, to an extent Electron is "language agnostic" since you write the UI in whatever language you want, you just then compile it to JS (and eventually WebAssembly).

As a thought experiment, how would the stack differ from Qt, which runs just about everywhere and has bindings for a huge range of languages?

The one thing that always put me off of the Qt, Wx etc libraries is that it felt like you have to be fairly deep in the weeds with layouts. HTML + CSS ( + something like a framework perhaps for JS niceness) feels much easier, because the browser does the heavy work of laying out the elements for you, resizing them etc. Maybe I've just not sat down long enough to poke the UI work, but every time I have sat down it's felt like a huge effort to get a few text boxes and a data table to render and flow, whilst over in web land, it's a few input tags and a set of table tags in a loop, and then a smattering of CSS.

https://doc.qt.io/qt-5/qtquick-layouts-layouts-qml.html

Doesn't look that bad?

Why not use the UI designer? It was made exactly for this reason.

Back to my prior point: how can I leverage the awesome tooling outside of C++?

If I can use any language with the awesome Qt tooling I am set. They seem to be working on making Python such a citizen in the official Qt languages stack but its taking forever and is only 1 single language.

Maybe they need to do what Godot did. Implement a bridging programming language that bridges any native language to their engine. With Godot I can write code in Rust, D, probably Nim and so on and all due to GDNative their bridging language to ensure you can use what you are comfortable using.

Ah yeah i agree there. Honestly the only way for this to be properly addressed is for a toolkit to commit to API and ABI stability (meaning C++ and any other language without a stable ABI is out of the picture), then people can build on top of it with other languages and focus on actually making the entire framework stable instead of rewriting everything every 4-5 years.

I think that's right. It's kind of sad. After decades of explosive tech growth, we're left with there being no really good modern desktop OS, and no cross-platform GUI that approaches the potential of the medium. It's a fragmented mess, full of accidental complexity & user frustration.

What is complicated about linux Mint or even Debian?

Gtk3 is awful and broke backwards compatibility with Gtk2 so you need to have at least those two in your system to run applications (since many still need Gtk2). Gtk2 does not get any meaningful updates anymore. Gtk4 will soon be released and repeat the cycle.

Same with Qt5, anything that needs Qt4 or less is now broken unless you use Slackware which tries to keep everything it ever had (it even has Gtk1). Qt5 is made by a company whose income doesn't come from desktop apps anymore and certainly not from being a stable API for a desktop environment. Though even if they wanted, C++ lacking a stable ABI doesn't help much.

The only alternative would be Motif but that hasn't got any meaningful update since the 90s and is only limping in life thanks to a company whose income seem to come from consulting about converting your Motif app to Qt.

Other toolkits either rely on one of the above, have largely been ignored and/or are even less stable than Gtk.

And the majority of all toolkits are way too bloated, not just in terms of resource use but also in terms of how easy they are for a developer to master them.

Neither gtk3 nor qt5 are particularly heavy as far as resources usage. Keeping older versions of libraries like gtk is the cost of keeping a rapidly shrinking cast of existing apps working. Note that qt4 and gtk2 are 7 and 8 years old respectively and can be used with current OS if needed by legacy apps. If your distro opts not to support it the dev or packager can ship it with the application. See flatpak or better nix.

The storage consumed is reasonable in terms of modern sizes storage.

Purely from the perspective of the end user I'm not sure I understand what the difficulty is.

The user doesn't care if the app is gtk 2 or 17. From the user's perspective they click install and an icon appears and their free hard drive space goes down a tiny amount.

I switched to using TUIs for everything except web browsing ~8 years ago (and I switched from GMail to Mutt ~3 years ago). I honestly can't imagine going back (I'm a Linux user so this might bias my viewpoint). GUIs either feel dated or sluggish, and I find that there are far more mature and continually-maintained TUI projects for most developer-related tasks than GUI ones. This is probably because (Linux) developers have a bias towards TUIs and so write tools that suit their workflow.

Another massive benefit is that I can seamlessly use all of the same tools over an SSH/Mosh connection. X11 forwarding over SSH has never practically worked for me (it's too laggy and Australian internet makes doing it between networks basically impossible).

the remote access is the key for me. my email is on a server accessible from any machine. sure, webmail could do that too, but webmail can't keep my state if i switch devices.

i now carry a tiny laptop (gpd pocket) where i have all my important stuff, including ssh keys to servers. i use any other available device as a workstation with a browser, and use ssh/mosh to access my tiny laptop to do the important work and access servers through that.

Just heard about the GPD Pocket for the first time, it's a fascinating little thing!

What is the keyboard like to type on and how fast can you type? Where did you purchase it?

i am not a trained typist, so i primarily type with index fingers and thumbs. that makes small keyboards much less of a problem than otherwise (before the GPD Pocket i was using an OLPC XO), and i type on it almost as fast as on a bigger one.

i got the first model of that series during their crowdfunding campaign. (it's their second product that they released 2 years ago) the keyboard on that was a bit wobbly, occasionally a key would not work (most annoying when typing a password), but for the most part it is usable.

the newer model is supposed to have a better keyboard, as i think the keyboard was what most people complained about.

it has plenty of diskspace and ram, to be practically usable, and if you got the right charger then you can hook up an external monitor and keyboard when at home or in the office, and have it portable otherwise. (and it really fits into my pant pockets)

Thanks for such a detailed comment :)

That is worrying that keys would stop working. I'd definitely be interested in a cheaper model with an ARM processor primarily for remote development on the go.

the keys don't stop working, just sometimes the keypress does not register. it's also only a few keys where i saw this happen.

but that's the first model. current models are supposed to have much better keyboards

I have the GPD Pocket 2, and I have no issues whatsoever with the keyboard except that I got some dirt spots from the keyboard on the screen easily (via each key's 4 edge points). Like, worse than my MBP 2015's.

The infrared mouse works OK (I'd prefer the thinkpoint-esque knob of the original GPD Pocket), but you can also attach a Apple Magic Trackpad 2 on it. These work very well if you run a new Linux kernel and patch up some software such as Xinput.

I run Kali Linux on it (its part of my pentest equipment; don't use it for e-mail and such [1]). Slapped an Apple logo on it for the fun of it.

Can I recommend the device? Well yes and no.

Its an OK build quality, and if you apply thermal pads and some copper you can easily run the machine without the fan on all the cores. It does get a bit more hot on the bottom then.

Its a bit expensive now, I'd say, compared to say the current Raspberry Pi 4 plus a powerbank plus a monitor. Its just 2018 price and hardware. Perhaps look at the successor(s) such as the black version or perhaps the Max?

Worst part is they screwed me over cause there's a clear spot on the top right due to attachment of the (touch)screen and in certain light / colors it is rather apparent. CS said they couldn't notice the issue. No warranty was provided. And even then I read about some people had to pay import tax once more receiving their (repaired/new) device but they want you to send the device without value (which means you could lose the whole thing if it gets lost). Typically Chinese.

[1] You could argue you shouldn't use such Chinese hardware for pentest purposes which is a fair point.

You can switch the last one (web browsing) to TUI as well via Browsh [1]. Uses Firefox internally.

[1] https://www.brow.sh/

I have been looking at trying out things like Vimperator to get a feel for no-mouse web browsing. But that looks even neater, I'll definitely give it a shot. :D

I do use Vimium (Firefox port) as well. I actually don't use Browsh much myself because I don't have a reliable, publicly accessible server available where I could run it.

I'm still using Thunderbird, which is barely maintained for a decent standalone IMAP client - it's beginning to feel pretty ridiculous. I was having some search issues the other day and I looked at alternatives - the options were basically Outlook, Claws Mail which is ugly as sin, eM Client which is Windows only and Mailspring which actually looked pretty good... right up until it asked me to make an account for use with my own IMAP servers - no thanks.

I didn't think this was a big ask but I guess now that most people just use a single Gmail account the market for such things is dwindling. Here I sit with 7 accounts in Thunderbird. Maybe I'm just going to be stuck with eM Client or Outlook and using RDP to check my email. I'm willing to pay, someone please give me a decent cross platform alternative with a GUI, ideally a proper, non-electron one.

The TUI clients I've looked at all seem to suffer from some mix of:

- Poor mail notifications

- Poor multi-account support

- Single maintainer that could disappear at any time

- Archaic keybindings, or perhaps I'm just too lazy to learn them

- HTML mail is used widely now as most people use webmail and just doesn't map well to console applications

Overall when I want my mail client to "just work" I've found them to be piss poor compared to Thunderbird. Which is beginning to seem rather silly, but it's still my experience.

I don't know what to do. Maybe I should fork Mailspring, strip out the account garbage and just tolerate Electron, but that'd create a whole bunch of maintenance work I just can't take on right now.

I'm kind of in the same situation, except that I've abandoned desktop mail clients since moving away from OS X. Mail.app had its problems, and seemed to be getting worse, but it's the only local mail client I've been able to tolerate for some time.

Now I just forward my IMAP accounts to gmail. This is horrible for many reasons (don't lecture me, I know), but I haven't been able to find a good solution and messing about with email is time-consuming.

I may just consolidate on Fastmail when my current IMAP provider subscription needs renewing. From a brief test a while back their web client seems to be on a par with gmail.

If you're looking to consolidate your email the best way is imapfilter https://github.com/lefcha/imapfilter I use this LUA script (this is the Jinja2 template so obviously you'll need to substitute the portions in {{ }} with your real values. It runs on an hourly cronjob on my server and sucks down all the mail from Gmail and another account and then puts it in my main inbox via IMAP (not forwarding) so you don't have to worry about opportunistic transport encryption. It also does not mess with the headers which forwarding emails invariably does.

  -- crontab -e
  -- 0 * * * * /usr/local/bin/imapfilter

  function main ()

      -- See 'man imapfilter_config' for an explanation of
      -- imapfilter options and functions.

      -- Some config examples:
      -- https://github.com/lefcha/imapfilter/blob/master/samples/config.lua
      -- https://gist.github.com/dylanwh/408810
      -- http://www.npcglib.org/~stathis/blog/2012/07/09/linux-task-sorting-mail-with-imapfilter/

      -- General Options
      options.timeout = 120
      options.subscribe = true

      -- Accounts
      {%- for v in ACCOUNTS | from_json %}
      local {{ v.serverName }} = IMAP {
          server = '{{ v.server }}',
          username = '{{ v.username }}',
          password = '{{ v.password }}',
          ssl = '{{ v.ssl }}'
      }

      {%- endfor %}

      -- GMAIL
      -- Gmail behaves differently to normal imap. With a normal imap acccount
      -- you can simply use move_messages(). Google stores both inbox
      -- and sent email in the "[Gmail]/All Mail" folder. An email sent to yourself
      -- from the same email address exists as a single email and is visible in
      -- the Inbox and Sent box. If you delete the inbox mail then the sent mail
      -- is also deleted. Thus it is only safe to delete mail once both the Inbox
      -- and Sent box is copied.

      -- Only go ahead and copy inbox/sent/spam from gmail if I have received
      -- some Inbox email.
      if (gmail['Inbox']:check_status() > 0) then
          inbox_mail = gmail["Inbox"]:select_all()
          inbox_copy_success = inbox_mail:copy_messages({{ PRIMARY }}['Gmail Inbox'])

          sent_mail = gmail['[Gmail]/Sent Mail']:select_all()
          sent_copy_success = sent_mail:copy_messages({{ PRIMARY }}['Gmail Sent'])

          spam_mail = gmail["[Gmail]/Spam"]:select_all()
          spam_mail:move_messages({{ PRIMARY }}['Gmail Spam'])

          -- Only clear the All Mail folder if we were successful in moving
          -- our Inbox and Sent mail. Note: move_messages is supposed to return
          -- booleans for copying the messages and then marking them as deleted.
          -- For some reason the mark for deletion return value is 'nil'.
          -- This may need to be [Gmail]/Bin or [Gmail]/Trash check your account!
          if (inbox_copy_success and sent_copy_success) then
              print('Safe to delete both inbox and sent')
              move_inbox = inbox_mail:move_messages(gmail['[Gmail]/Trash'])
              move_sent = sent_mail:move_messages(gmail['[Gmail]/Trash'])

              if (move_inbox and move_sent) then
                  print('Emptying bin');
                  bin_mail = gmail['[Gmail]/Trash']:select_all()
                  bin_mail:delete_messages()
              end
          end
      end

      {%- if SECONDARY != '' %}
      -- {{ SECONDARY }}
      -- Only go ahead and copy inbox/sent/spam from {{ SECONDARY }} if I have received
      -- some Inbox email.
      if ({{ SECONDARY }}['Inbox']:check_status() > 0) then
          inbox_results = {{ SECONDARY }}['Inbox']:select_all()
          inbox_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Inbox'])

          sent_results = {{ SECONDARY }}['Sent']:select_all()
          sent_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Sent'])

          spam_results = {{ SECONDARY }}['Junk']:select_all()
          spam_results:move_messages({{ PRIMARY }}['{{ SECONDARY }} Spam'])
      end
      {%- endif %}
  end

  main()

Looks good (thanks), but my days of running servers for anything are long gone. My tolerance for anything sysadmin-related has reached very close to zero.

> Looks good (thanks), but my days of running servers for anything are long gone. My tolerance for anything sysadmin-related has reached very close to zero.

You don't technically need a server.

It's a very simple, single binary that runs on a cron job with no dependency other than lua. I do it on a VPS instance that I have, but there's no reason why you couldn't run it locally.

I have my gmail accounts forward to fastmail (And then filter). I've had this setup for years now, not sure exactly but easily 5+ years, and I'm super happy with it.

I do really wish I could find a better email client though, but Thunderbird is "good enough" for now. I don't get a warm fuzzy feeling using it, but I also don't rage at it not working constantly.

I was thinking of just using the Fastmail web app. I found it (like gmail) better than any current desktop email client I've tried.

I couldn't agree more, and for the same reasons you've mentioned I end up coming back to Thunderbird, even though I'd like a TUI client.

I looked at this video about mutt https://www.youtube.com/watch?v=2jMInHnpNfQ which made me think about making a switch.

However can we really do better than Mutt. Mutt typically had issues with multiple accounts and moving emails between the two. I have been migrating away from Google and this is a handy ability (which thunderbird has). I was quite excited by Drew Devault's aerc client https://drewdevault.com/2019/06/03/Announcing-aerc-0.1.0.htm... so maybe that or meli might be the solution for me.

Really there are only 3 requirements for me:

* Be able to use Vim for editing (one of my major gripes in Thunderbird

* Be able to use markdown, ideally something like pandoc, in thunderbird I use Markdown Here https://markdown-here.com but that requires you to edit in rich text mode and then convert to markdown. This is really annoying because you end up with <br> and <p> in the wrong places and have to always convert back to "Body Text".

* Be able to sync my contacts from CardDav. I could not go back to having a non-centralized address book. Ideally such a client would benefit from https://www.etesync.com/ as well

* Calendars I don't think need to strictly be in a mail client. What's the usecase for that? MacOSX has Mail.app and iCal.app separate. Is this a hangover from the Outlook/Google design. https://www.calcurse.org looks pretty healthy, though they say their CalDav support is experimental.

* PGP support, WKD, OPENPGPKEY, AutoCrypt etc. Enigmail does a lot of things right.

Your needs would line up pretty well with switching to emacs/evil, orgmode and then one of the 3 good email clients.

Just remember its there when you are ready for it ;)

Just looking at the requirements of both of you shows how hard it is to make a decent mail client.

I’ve never really had issues with mutt: the lack of notifications is, from my perspective, a good thing because it means that I’ll handle mail on my own schedule rather than as it comes.

As far as multi-account goes, though, it’s relatively easy to setup in mutt, using something like isync and mu for archiving and searching.

Thunderbird has a big problem - UI still looks like written in 90's. I'm switched to Geary, good Apple Mail clone.

Why is barebone UI a problem? What feature a UI looking like it's written in the 90's is preventing?

Of all problems Thunderbird has, the look and feel of the UI is the least of my problems actually. Maybe it's just how I use mail, but probably like 90% of interaction with the UI is that white space where I read and type email text. I don't really care, or even notice, what's shown around that white space.

For email, designed like it's the 90s is a good thing, in my opinion. Thunderbird could do with a bit of polish, sure, but it has every option under the sun. I tried Geary once, it looked shiny, but the interface was far too basic.

That's a feature, not a bug.

On poor mail notifications and poor HTML support, those are strengths. Email is not a real time communication mechanism and most emails I receive I'd be happy to never be notified about, it's mostly just a deluge of unnecessary information. The same goes for html email, it's just an unnecessary intrusion into life from marketers obsessed with their branding over my convenience.

When everything on your phone and desktop is constantly seeking your attention it's nice to have some apps working for you.

I do support work for my small business via email, I need to know if a network is having problems, when a server goes down, if any users are having payment issues and jump in to fix these immediately if not sooner. A console ding as an email notification that I can't differentiate from pressing backspace one too many times is absolute trash.

Ideally I want Android-style reply in the notification level stuff.

I still find Opera Mail works best, even though it is unmaintained. It has superfast search and not as sluggish as Thunderbird.

With Opera mail you can create many Bayesian filters to categorize your inbox. The obvious category is spam, but you can also have it automatically categorize into business clients projects offers family etc, each type of newsletter can have its own category.

Evolution mail and Geary, GNOME’s big and little email clients, respectively, are the best options right now. Both are great.

Geary looks great, i wanted to switch to it years ago (from Thunderbird), but it had no support for PGP – https://gitlab.gnome.org/GNOME/geary/issues/6 :(

I agree. Geary looks great and mostly works fine—I don't need extensions or calendars.

I did have an issue in early 2019 where parsing of contact names somehow got messed up, causing outgoing messages to not get sent. After a few productive days of sending emails I found twelve in my outbox that hadn't actually sent! I got scared and went back to Thunderbird after that, but I keep Geary installed and launch it from time to time to sync my mail.

Agreed, I've been really happy with evolution

This is the exact reason I opted to donate $3 every month to Thunderbird, I got really scared when Mozilla abandoned it and even though it's slow, bad UI and all of that, it's the only GUI mail program which somehow works at all for my workflow. I also have 6 accounts and want to be able to work offline.

I have been using alpine (re-alpine before that and alpine before that and pine before that) for about 20 years and it ticks most of your check boxes:

- Email notifications just work. I get a bell on my terminal when a new email comes and my desktop environment (i3m) shows a highlighted xterm and a highlighted workspace so that I know that I have a new message.

- Excellent multi-account support. I have 4 email accounts and I can seamlessly move messages between them.

- It had a single maintainer who disappeared, someone else took over who disappeared, and now there is a new maintainer.

- The keybindings are relatively simple (n for next and p for previous) but the arrow keys and mouse also work.

- You can view html emails using w3m or lynx or whatever.

It supports standard features such as choosing your own editor to compose emails (default is nano, which is a successor of pico, which was the editor used by pine), filtering a message to a program (for example, to git apply patch), filter a message before sending, multiple ways to display threading, and so on. It has working support for signing and encrypting messages, decent support of reply templates. It has really really good documentation available in a context sensitive manner.

I sometimes feel that alpine/pine doesn't get as much love as other TUI email clients.

> I'm willing to pay, someone please give me a decent cross platform alternative with a GUI, ideally a proper, non-electron one.

Have you tried Postbox? It's cross-platform Mac/Windows, native non-Electron (actually forked from Thunderbird long ago), supports multiple accounts, lots of keyboard shortcuts & paid non-subscription product developed by a company. I've been using it ever since Eudora died, it's the closest I've found to that Eudora power user workflow. It's a GUI app though, not a terminal app.

https://postbox-inc.com/

I appreciate that a lot of people use Mac and/or Windows, but calling it cross-platform and then excluding the third big platform option is I think missing the point.

Technically if it supports more than one platform it is already "cross-platform". It is not "every-" or "all-platform".

Technically true! What I said was that it was missing the point, not that it wasn't literally true :)

There's also Mailpile, which is GUI (webapp) but FOSS self-hostable.

https://github.com/mailpile/Mailpile

How's the multi-account and desktop notification support in it? I can't find a lot of details on what it does, but there's a mailpile-desktop package that seems potentially promising?

Also, the default IRC message compose in Thunderbird is white text on white background.

"I was having some search issues"

This can be easily fixed. Try using Evolution for a while and you never complain about search issues with Thunderbird. In fact, you will praise Thunderbird for its search features. If still something is lacking, install recoll on your system to find stuff.

I would pay for an email client too.

> Poor mail notifications

Time for someone to write an Electron-based update to the venerable "biff"[1] program.

[1] https://en.wikipedia.org/wiki/Biff_(Unix)

I'd really recommend you take another look at Mutt, or Alpine if you're more into pico/nano than vim as editors. It's the best tool I can think of for dealing with large quantities of mail.

* Notifications can be configured to do pretty much whatever you want (by invoking a command when new mail arrives)

* Multi-account support works well (currently have it hooked up to my personal and work accounts simultaneously)

* Developed by a community

* The visual component of HTML mail is irrelevant 99% of the time. A reasonable textual interpretation can be generated by piping the message through `w3m --dump`, a process which can happen automatically inside mutt when viewing those messages with no action required on your part. If you absolutely must see the formatted message with images and such, this is only a keystroke away.

There's a lot of initial configuration to do, granted, but you only need to do it once. Then you stick your mutt directory up on github or similar, and never need to do it again. Setting up a new or different machine is a clone away.

You can learn the initial keybinds in a couple hours (it's a lot simpler than vim), and I think you'll be blown away once you get proficient at it.

This may be a bit extreme, but after many years, I think all GUI mail clients suck. Email is primarily a textual medium at the end of the day.

That, and Mutt's the only thing I can think of where the expected features of a mail client work with reliability. Putting up with Thunderbird's speed/stability or Outlook's stability/searching isn't something we should have to do in 2019.

> I'd really recommend you take another look at Mutt

I think I will do that.

> Notifications can be configured to do pretty much whatever you want (by invoking a command when new mail arrives)

My understanding was that was pretty trivial to have going using notify-send and aplay

https://neomutt.org/feature/new-mail

> Multi-account support works well (currently have it hooked up to my personal and work accounts simultaneously)

Admittedly when I looked at it was pre neomutt days, I seem to remember there being a special sidebar patch that upstream refused to use.

https://www.youtube.com/watch?v=mPiQuWbF57M Mutt Wizard Published on Apr 25, 2019

In that video he demonstrates a loose script that he's developed https://github.com/LukeSmithxyz/mutt-wizard, it might be a good way for me to dip my feet in it and learn about all the components.

https://www.youtube.com/watch?v=hvc-pHjbhdE he did a video on calcurse too..

Sorry for the gaudy 4chan-style meme stuff. That's not my thing either but the videos are very succinct and he seems to be a good speaker.

> Developed by a community

Yes, this important to me and more likely to make me help out.

> The visual component of HTML mail is irrelevant 99% of the time. A reasonable textual interpretation can be generated by piping the message through `w3m --dump`, a process which can happen automatically inside mutt when viewing those messages with no action required on your part. If you absolutely must see the formatted message with images and such, this is only a keystroke away.

Very true, most of the email i receive is plain text, sometimes its not, but with minimal formatting. Theoretically it should be possible to view these HTML emails in Firefox should it not?

> There's a lot of initial configuration to do, granted, but you only need to do it once. Then you stick your mutt directory up on github or similar, and never need to do it again. Setting up a new or different machine is a clone away.

This.... the main reason I like plaintext configs.

I almost had to check to see if this wasn't posted by me, right up to the no thanks with respect to Mailspring requiring an account.

and I'm right there with you about being willing to pay. Thunderbird is what I use, but I'm always asking myself if there's a better way.

I think you might want to trial the Thunderbird-powered Postbox https://www.postbox-inc.com/

If you’re on Mac, Mailmate might be what you’re looking for.

I also think many GUI are too bloated or other problems (and most widget sets don't implement scrollbars like Xaw, and use antialiased fonts with too much kerning, and other problems). TUI can help many things, although also command-line interfaces are. (I use Heirloom-mailx, which is email program with command-line interface; and I am also writing a NNTP client software with command-line interface too.)

> and most widget sets don't implement scrollbars like Xaw

Do you consider Xaw scrollbars a feature? They feel totally inconvenient to use with their weird "the position you click at is the amount to scroll and the button to use is the direction to scroll" behavior. The only way i use such a scrollbar myself is with middle clicking since that is the only way i find them usable.

I consider it a feature. It might be better if right-clicking used the distance from the end instead of from the beginning as the amount to move (so that the clicked position would then be on the bottom of the screen, like left-clicking scrolls the clicked position to the top of the screen) (but also, maybe it isn't better that way), but it is still better than Microsoft scrollbars I think. I use all three clicks on it, and I think it isn't inconvenient; it is good.

GUI stacks, since the Mac OS X / CSS3 days have become form over function most of the time, for better or worse. I personally appreciate beyond words nice enough, keyboard oriented TUIs. The lack of cycles dedicated to rendering shit I can't bother with anymore makes my brain ultra happy.

Working in a terminal let's me do everything with the keyboard.

Not touching a mouse is a big plus. It may not bother you now but it probably will in a few years.

TUIs aren’t getting any more or less attention than they’ve always gotten.

I guess you could argue that with the recent-ish rise of new CLI-friendly languages and frameworks like Go, Rust and Node that the people are reinventing the wheel in terms of terminal based tooling. However there has always been a strong undercurrent of people favouring the terminal for most types of work (myself included).

Some TUIs even have mouse (optional) support.

vim has that, and it drives me nuts. i use the mouse to select text in a terminal to copy it elsewhere outside of the terminal, but when vim is running that doesn't work, and i end up disabling mouse support every time because of that.

Yeah, mouse support seems a little pointless at the best of times but in vim it’s down right annoying.

I wonder if it would be possible to do a GUI mostly-drop-in replacement for ncurses.

Immediate advantages, at least for me:

- a possibility to use proportional fonts, it's more pleasant for me and increases content density

- borders and other decorations could be smaller, increasing density

- smooth scrolling could be implemented, which is nice

- it could better integrate with desktop environment

Possible and very much desired extensions:

- basic image and video support

- possibility to use different font sizes

It would still be limited to a coarse grid, but that's what makes development easy.

I never looked beyond superficial it's possible or easy enough to do. I also don't have much experience, beyond basics with ncurses.

i had similar thoughts. what would a modern terminal look like? one where positions and cursor movements are not defined by obscure escape codes but by a proper API.

Emacs in a way does something like this: just about any emacs app (including mail clients) can run in either terminal emacs or GUI emacs, and the GUI version supports proportional fonts, images, etc. Of course building your TUI app on top of emacs instead of ncurses isn't for everyone.

> With all respect for the hard work done on this client, but is it just me or is the TUI getting too much attention recently??

I, for one, cannot get enough of this. Faced with the choice of a performant and full-featured GUI and a slightly slower and worse TUI, I get to chose the text interface 100% of the time. It is so much more convenient!

You're observing something else: software people are the only ones obsessed enough with improving their tools to continuously debate and re-invent them.

Sadly this obsessive search for the ultimate workflow becomes a goal unto itself, leading to a life-long unsuccessful and unsatisfying search that is doomed to fail.

Meanwhile, in the real world GUIs have long superseded any text-based UIs, speciality tasks aside. E-mail is not a special task...

The reason terminals and TUIs are still prevalent in tech circles is that it is a fairly good lowest common denominator. It makes sense to implement interfaces as TUIs. This then creeps into "higher-order functions" such as the terminal integrations for GitHub, or these new TUIs for e-mail. TUIs are basically 100% portable, there is no "does this work in Firefox and Safari?" worries, and the upfront development cost is lower because there are no inherent network transfers as in HTML/JS.

No, it didn't get enough before because everyone thought they'd need some shiny sht.
Instead TUI's work just fine for a lot of things while consuming less of your computers resources as well as being easy on your eyes and state of mind (no hectic blinking and notification banners and sounds distracting you from everything you do).
Just because we have more resources and faster computers doesn't mean we should max them out. Use less and you could have a device with enormous battery duration, blazingly fast and easy on the mind.
They even support mouse interaction and enable me to work for some hours with an old thinkpad before the battery dies.
With mail it's something different in my opinion. While it was easy to get used to VIM, nmtui, newsbeuter etc. I could never get my head around mutt.

I hate to use Thunderbird because of the UI/UX and some missing features and I miss the seamless integration into the OS (click on a date in a mail to create an appointment in your calendar*) but it's the only good working mail client out there I know.

Mailspring/Nylas has a really nice interface but as another user wrote it wants to steal your credentials and I don't like that.

Electron is okay as long as it helps providing a better UX, for me that is one of the most important features besides stability & security.

As a calendar app "MineTime" is the best I've seen out there so far and sometimes I wish I'd have a bunch of apps like these for a great "FOSS Desktop Experience".

@author: Great work - hope you create something like mutt and alpine that can enrich the ideas in the world of TUI mail clients.

I wonder about the TUIs consuming less resources. Sure, compared to something like Electron, they will, but on the other hand, pretty much everyone is running a TUI in a graphical terminal - often a terminal with unicode support, utf-8 decoding and antialiasing, sometimes subpixel antialiasing with all that overhead it has. In that environment trying to, e.g., fill a silver rectangular area implies sending all the ANSI escape codes to move the cursor and change the current color, send a ton of characters that represent a "full" block, have the terminal emulator parse all that and then fill the area with lots of tiny rectangles (assuming it does know about the full block character and doesn't just defer to the font engine which does the full block drawing itself using the entire text rendering stack).

In comparison a GUI application would just draw a filled rectangle. For a local X11 application or OpenGL application this may even done as a hardware accelerated operation without even touching any pipes.

To me the "graphical" side of a TUI (which is pretty much most of it) sounds way more heavy than the equivalent of a GUI.

That's an interesting point and I can't really compare that.

But I noticed with an old thinkpad (x220) that I can reduce overall resource consumption and prolong battery life just by switching everything I can to a more terminal-centered workflow.

Ranger consumes less than dolphin, I use NMTUI because i3wm doesn't have a clickable task bar item for configuring WiFi (at least in my setup) and VIM/NVIM consume less than VSCode, IntelliJ, Atom or other editors.

Clearly there is a difference when you compare an electron app to some other running in the JVM or natively but in the end I have the feeling that terminal apps run better and faster.

Another very important thing in my opinion is the possibility to use these apps via SSH which is still my preferred way to remotely use computers (no VNC, RDP, teamviewer etc.).

For anyone else unfamiliar with the term, TUI appears to refer to "Text-Based User Interface"

> started doing TUIs

Terminal-based interfaces predate GUIs and have never really stopped being popular among a specific crowd. Perhaps they are gaining more traction now because of all the warts that current popular GUI frameworks have, but it is by no means a new development that is suddenly happening.

TUIs are as cross-platform and network-able on as many clients as you are able to run SSH clients on. They also support resuming (via a terminal multiplexer such as Tmux/Screen; tmux itself can also support session resuming via a plugin), windowing/tabs (via term mux), scrolling (via term mux). So your TUI program does not need any of these features. If you have a computer running 24/7 you can connect to term mux over SSH from anywhere you want. If you have high latency such as LTE or bad WLAN, you can use Mosh to easy with the latency. Either you, you aren't using a lot of bandwidth with a TUI. You can also use the power of the UNIX shell easily together with a term mux. For example, jessfraz runs all her CLI commands in Docker.

Why I like it? Well, if you're a Emacs user and you can get everything to work with Emacs-esque keybinds that's great. Same with vi(m) keybinds. With Mutt, its a matter of setting EDITOR right and you can compose your e-mails with vi(m) (yes, you could set EDITOR to something more nefarious ;). You don't get to make such choices with a GUI e-mail client.

If it gets the job done, and creates some value for the user, the user will go over hoops in order to use it (even pay money) ... I find it funny that we are still emulating old terminals. And still building new apps for them. Plain text however gets the job done. It's very powerful to search for a solution on the web, and find instructions on how to do just about anything by copy/pasting a bunch of commands into the terminal. Personally however I prefer GUI's because I can't seem to remember all the commands or keyboard-keybindings unless I use them daily. And if done correctly, a graphics interface can be more intuitive and have better feature discovery compared to a text interface.

We seem to be experiencing a renaissance of TUI software, particularly email clients[1] and I couldn’t be happier.

Email and TUI are such a natural fit. Make it work with your favorite editor and most nerds will switch.

[1] https://aerc-mail.org/

In absolute agreement here. Even though mutt's shortcuts are hardwired into my brain, I always check the new-comers out - especially ones written in a language that compiles to binary. There is something lost in this world of shady docker containers, epic javascript runtimes and infinite universe of python environment versions.

I, for one, want a pure command line based email client, not just a TUI client, that is well integrated with bash/zsh in an everyday use, e.g.

    $ inbox
    (shows the first 10 emails in the inbox)
    $ search from:john
    (shows emails from john with numbers)
    $ reply 4
    (opens up vi to edit a reply to the email #4)
    ...

I've been dreaming a client like this for decades, and actually started developing it, but the development is stagnating for now (due to the spec changes and other priorities).

Check out notmuch:

https://notmuchmail.org/

I loved your take, haven’t thought of it that way, but it would be great. I hope you are able to go back to it.

You might find mblaze (https://github.com/leahneukirchen/mblaze) interesting; it's not too far off from what you describe.

mail, pipes and grep?

did you look at nmh? https://en.wikipedia.org/wiki/MH_Message_Handling_System

Actually, I was a big fan of MH. But it's quite old and full of gotchas. It doesn't have decent search functions either. Also I'd like to have something written in a modern scripting language (Python, JS, etc), as I don't want to worry about buffer overflow.

Isn’t this mh?

yep

Haiku's mail system may be of interest to you -- the default UI is of course a GUI, but as the mails are stored as individual files, and their headers in extended attributes, you can use "query mail:from=john", etc. to filter mails, "mail" to send them, etc.