viewmail-info
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VM] Time to move to Mutt?


From: Tim Cross
Subject: Re: [VM] Time to move to Mutt?
Date: Wed, 24 Jul 2019 10:26:52 +1000

Hi John,

just a few brief comments  in-line to clarify some points.

On Mon, 22 Jul 2019 at 23:49, John Stoffel <address@hidden> wrote:

Hi Tim,
Thanks for your long reply about the switch to mu4e, which sounded
familiar to me, but only after I spent some time looking did I realize
it's an emacs frontend to the 'mu' project.  Which I recall looking at
but decided it wasn't what I wanted.

I guess my desires  are:

1. IMAP support that works well.  VM is pretty close here, but slow at
   times.  Need this for multiple device support. 

This is how I use mu4e. While mbsync does download local copies, it does not remove them from the remote server, so they are still accessible from other devices. When setup correctly, it synchronises things, so when I look at my mail from my phone for example, messages I've already read are flagged as read and ones I haven't are flagged unread. Likewise, the sent and deleted items are synced, so I can see messages sent  regardless of where device they were sent from. I access my mail from phone, tablet, emacs and outlook/apple mail (work) - all synced. 

mbsync is still slow - probably faster than VM imap, but as I run it as a daemon, I don';t really notice that. My mail is just updated every X minutes.  

   mu/mu4e and other non-IMAP based tools just don't fit into my needs
   which is seemless access to all/most of my email from both VM and
   other clients. 

2. emacs editing/searching/composing for basic key bindings.  Again VM
   works well here.  I do have thoughts on more M* bindings for more
   grouping options, such as by sender:, list-id:, etc.  It would be
   nice to be able to mark by arbitrary headers more easily.

mu4e is very powerful in this area - as good as VM IMO, but of course, it has a learning curve. It uses the Gnus message mode for composing mail.
 

3. HTML -> Text support.  I read VM exclusively inside SSH/putty
   sessions.  I never use emacs in GUI mode with inline graphics.
   Maybe time to do so?

By default, uses Emacs eww, which is pretty good. I've not bothered with w3m for quite some time now due to eww.
With the right setup with browse-rul, it is also easy to have things so that when you want to, you can send the message for display in the GUI browser. Most of the time, I just use eww though.
 

   a. An easy way to find and copy URLs so I can copy them to use in
      my local web browser would be nice.  I just found out about the
      [ and ] keys in w3m mode, which I currently use, even though it
      annoyingly over-rides the 't' mode to toggel showing the full
      headers.

You can easily setup key bindings to use browser-url to send links to your web browser.  

   b. A bunch of times I'll save an email and pull out my phone just
      to look at the images or to find and click on that damn
      un-subscribe link button hidden deep in the HTML stream.  LOL.

But don't get me wrong, I find VM makes my life so much easier (even
though my friends whine about how funky my supercite'd emacs look on
their phones when they read email....

Its be best too I've found so far, I just wish we could do more.

I think of VM with considerable fondness - I used it for many many years and if it wasn't for the issues I had with IMAP, I probably would have stuck with it. The issue with it is, as you note, the small user base. Another contributing factor is that VM also gtries to do most of what it does itself, which can mean it is more immune from external changes, but also means it is larger and more complex, requiring more maintenance. Mu4e on the other hand is more minimal, buit still as functional. It takes greater advantage of already existing functionality e.g. Gnus, shr/eww etc and delegates some responsibilities to external apps (mu, mbsync). 

Stick with VM as long as you can. However, when that is no longer viable, consider mu4e. I suspect it will meet most, if not all, of yhour requirements.


--
regards,

Tim

--
Tim Cross


reply via email to

[Prev in Thread] Current Thread [Next in Thread]