And that, my friend, is modern day integration between gVim and GMail on Windows.
And that, my friend, is modern day integration between gVim and GMail on Windows.
Actually, there's no reason for this to depend on the cli. In Firefox, there are plugins which give you a button to click under every text box which open your favorite text editor with a buffer already open containing the contents of the text box. Edit the buffer and save, and your changed appear in the text box. (This is, in fact, how I am editing this comment.) On Unix systems, a graphical mail program could easily use a shell call to get text from an external program. The only problem is, this just doesn't really happen. Vendors prefer proprietary interop with their own products rather than more universal interop methods.
Personally, I type the above sequence pretty much instantly, though, so... I don't mind: http://screencast.com/t/jw0LFrlBg
He gives the example of _nmh_ for email reading. I've been trying it out all morning. I think the stock _mail_ program seems to be better (although I use alpine on the CL). I need to do extra work to see gmail messages with _nmh_ (not with mail).
>mhshow: don't know how to display any of the contents > (content multipart/alternative in message 2)
Also, the _comp_ command for composing a mail launches vim (unable to stop that) which gives an error on what_next. I tried pico, that works.
Not sure _nmh_ is the way to go today. If I had to use the CL, I'd use _mail_ instead.
command line mail clients dont need any of that. you edit it in vim and send it from vim. or you edit it from your email client THROUGH wim and send it also directly.
No utterly long key combo. No app switching. No delay. No complexity. No cut-and-paste.
That is the actual point.