Setting up mutt for GMail these days is no harder than setting up vmail. This is a complete config file for mutt that will connect to your gmail account:
set folder=imaps://imap.gmail.com:993
set spoolfile=+INBOX
set imap_user='your_username@gmail.com'
set smtp_url = "smtp://your_username@smtp.gmail.com:587/"
If you don't want to enter your password every time, you can set it as imap_pass (for reading) and smtp_pass (for sending).
Exactly. I don't understand the advantage of "vmail" over mutt, which is extremely powerful and mature, and of course can be configured to use vim, -- but I admit I just skimmed the link, so I could be missing something.
Note also that you must use caution when using Google's smtp and other network services, as they tend to do whatever they want, regardless of RFCs and standards[1].
You could also look at it like carrying a cigarette lighter with you that you like rather than using whatever fire making tool is around when you need one.
That'd be hugely appreciated (at least from me). I've been using nmh+fdm on a trial run for a secondary e-mail account for a bit but would love to see an actual flow blown setup.
Does it have support for two-factor auth? In the event of 2FA/MFA, I'm assuming one needs to generate an application-specific password and keep that in the .rc?
Alternatively, I see there are requests for using OAuth, which would be a similar approach to have a "token" that can be revoked.
While this is awesome, I am one of those guys who feel uncomfortable to store my raw password in a dotfile, not to mention I'm managing my dotfiles in Github, authentication in every run doesn't seem convenient either. I see that this happens in other places such as Github gists-terminal and some twitter-terminal clients. Is there any way we can store these credentials locally in a safer way like SSH keys?.
I think what he meant was seahorse. I just tried it out and I can see my raw passwords by clicking properties and ticking 'Show Password'. Shocked as well, not to mention seahorse is launched without asking my password.
> I can see my raw passwords by clicking properties and ticking 'Show Password'.
As opposed to what? They need to have access to the plaintext passwords somewhere; it's just encrypted when it's stored on disk.
> Shocked as well, not to mention seahorse is launched without asking my password.
The default keychain uses your login password, and it's unlocked at login. This is easy to change if you want to have to unlock it every time you use it.
This isn't shocking; Mac OS X will also happily show you your passwords. It stores them encrypted, then decrypts them for you after your keychain is unlocked.
Many programs that require passwords (e.g., mutt, offlineimap, msmtp) let you specify a command to retrieve the password, which is really easy using pass.
I love it. For decades, my flame war offensives against the evil crusaders of Emacs have stalled out against their Maginot Line of "But Emacs can be your mail client too!" This is like a Blitzkrieg of flame war glory. PARIS PREPARE TO BE MINE!!!
Especially with utilities such as Vagrant[0], for which there are many ready-made boxes[1] that make short work of spinning up new VMs. My main development "box" is a VM on a win host and it works wonderfully.
This is pretty awesome. I've used Mutt in the past but always found it a little bit over-the-top. This is very, very simple to setup and does the job pretty well.
But better than that... oh my word, the documentation. How I wish every command line app had that kind of documentation. Just one page that documents the shit out of it.
There's only one thing that would make it better: if that documentation came bundled with the RubyGem so I could read it offline with `ri`.
Oh certainly no ulterior motive, but these things never have ulterior motives, just good people not doing what they should. I was just curious why it wouldn't be just as easy to make it use imap rather than being gmail specific. The idea of making an email client that only worked with email addresses from a single domain would not even have occurred to me.
For instance, Gmail does support IMAP but also has non-IMAP features. Being too abstract would mean avoiding providing these features.
Another point is the easiness of installation/configuration/usability. For instance, with Emacs, you can use GNUs to read gmail. However, it is so generic (you can read usenet news and any kind of e-mail), that it's really a pain to get started. There are terminology confusions (i.e. you need several hacks to have a gmail-like inbox) and overall, it just doesn't feel like g-mail..
Also, by starting very specific for our own problem, it's easier to create a meaningful product that solves a real need. (Like startup!) I think it's easier to start specialized and then grow larger, than start too brood.
Apparently some people in the world use gmail. He wrote something that will be at least interesting to try, so why should he feel any "pain in his soul"?
go there and make something too, instead of hoping for other people's souls...
I mean a full blown browser of current generation abilities, but with the option of completely keyboard driven interaction. Concise input of small commands (navigation, data extraction, exploring and massaging of extracted data, data uploading etc.) that can be composed to form more complex interactions.
It should have full interoperability with the CLI, don't go re-inventing grep, sed etc. but instead stand on their shoulders by interoperating fluently with them. In practice i expect this means the "programer's browser" functions as a full blown terminal emulator too.
If it were a text editor (and it should be a competent one of those, but the web is more than a textual medium so some implementations should certainly offer richer functionality than plain text editing) then the net and its many protocols would be its filesystem.
It should be extensible, but only by 1 language. Competing programer's browsers could offer alternative extension languages as their differentiator.
It should be entirely open for extension, by that i mean more than plugins, i should be able to rip out core parts of it to be replaced with alternative implementations (A's needs won't match B's needs and so on).
It shouldn't go too far though, it shouldn't be a full blown operating system: why re-invent the wheel, reuse the thousands of man years effort in existing OS's. It should be multi platform.
We almost have the requisite component parts available now, who's going to get the ball rolling with the new wave of "programer's browsers"?
For now, as has been pointed out, the answer is uzbl.
(Almost exactly what you describe is my current dream project, pieces designed, pieces roughed out, no part even remotely finished. The one I will get back to working on as soon as my startup exits and I have money and time. Or when it fails and I have time. You are not alone in wanting this.)
There's luakit, uzbl, surf and jumanji from the top of my head, but I don't think any of these have "full interoperability with the CLI". luakit is definitely my favourite as it has been much more reliable than uzbl and easier to configure/extend (in lua).
I feel like the Web is evolving too fast right now for this kind of things to happen. It's already ridiculously hard to keep up with all the innovation, so there is no time to stop and reflect and build a browser from scratch with a clean and modular design. Maybe it will happen once something different than the Web takes off.
To add to your specifications: a "programer's web browser" should communicate with the user in a way which assumes that the user is knowledgeable. It should not use ridiculous metaphors like "this site could harm the computer! back to safety" or noob-oriented advice like "check the address for typing errors", but tell me things like "this URL is registered as a phishing site in such and such blacklist", "access to this site would violate an STS policy", "no DNS record for this domain, here is the result of the lookup", "no reply from IP A.B.C.D, here is a traceroute", etc.
My current choice of a keyboard-oriented browser is Firefox with the pentadactyl extension. It's not perfect, but better than anything else I've tried (including uzbl, which doesn't seem mature or well-documented enough).
I use Chrome with Vimium when I want to do development, but I still prefer Safari for browsing. Something about having those tools away from me helps me grok whatever I'm reading...
> To save you keystrokes, Vmail provides alternative key mappings for ,* , ,#, and ,!
Unfortunately, vmail doesn't seem to consider internationalization important at all. US users save a single press of the shift key when starring messages (,8 instead of ,*), but on a german keyboard, where the star is shift-3 instead of shift-8, the shift-less version of starring trashes the message instead. Not a typo I'm eager to make.
One, just as another user pointed out, remapping is easy.
Two, I personally think that most international keyboards I have used have been any good at all for the tasks we face as programmers/hackers/developers. They put an emphasis on producing text, not code, and if you spend most of your day typing code and English anyway I can't see why we should "waste" precious keyboard real-estate.
I ditched my Swedish layout during my first year at university, went US-style and remapped the three keys that I needed to type "native" characters to Start-key combos. I haven't looked back since. It was also the point where I started touch-typing.
I did that, too. But I constantly switch back and forth when I'm writing German code (think LaTeX). Pure coding is fine, and so is pure prose, but whenever the two mix, its a pain.
79 comments
[ 3.2 ms ] story [ 144 ms ] threadEvery program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
If you're on Linux, it's also rather simple to store this in a keyring such as gnome-keyring (Seahorse).
Note also that you must use caution when using Google's smtp and other network services, as they tend to do whatever they want, regardless of RFCs and standards[1].
[1]http://lee-phillips.org/gmailRewriting/
Not a smartass question.
https://github.com/richo/homebrew/blob/master/Library/Formul...
Alternatively, I see there are requests for using OAuth, which would be a similar approach to have a "token" that can be revoked.
As far as I am aware, this is currently a limitation of any third-party client that connects to Gmail.
I don't know if there are many clients that support it yet, though.
http://www.dribin.org/dave/blog/archives/2006/01/16/keychain...
https://developer.apple.com/library/mac/#documentation/Secur...
[1] https://wiki.archlinux.org/index.php/GNOME_Keyring
Gnome keyring definitely uses encryption to store passwords; they take security pretty seriously: https://live.gnome.org/GnomeKeyring/SecurityPhilosophy
As opposed to what? They need to have access to the plaintext passwords somewhere; it's just encrypted when it's stored on disk.
> Shocked as well, not to mention seahorse is launched without asking my password.
The default keychain uses your login password, and it's unlocked at login. This is easy to change if you want to have to unlock it every time you use it.
Many programs that require passwords (e.g., mutt, offlineimap, msmtp) let you specify a command to retrieve the password, which is really easy using pass.
Tetris in Vim: http://www.vim.org/scripts/script.php?script_id=172
Towers of Hanoi: http://www.vim.org/scripts/script.php?script_id=900
[0]: http://vagrantup.com/
[1]: http://www.vagrantbox.es/
But better than that... oh my word, the documentation. How I wish every command line app had that kind of documentation. Just one page that documents the shit out of it.
There's only one thing that would make it better: if that documentation came bundled with the RubyGem so I could read it offline with `ri`.
Why on earth would you do that?
How short of a memory does this community have if they don't understand what comes after "embrace" and "extend"?
For instance, Gmail does support IMAP but also has non-IMAP features. Being too abstract would mean avoiding providing these features.
Another point is the easiness of installation/configuration/usability. For instance, with Emacs, you can use GNUs to read gmail. However, it is so generic (you can read usenet news and any kind of e-mail), that it's really a pain to get started. There are terminology confusions (i.e. you need several hacks to have a gmail-like inbox) and overall, it just doesn't feel like g-mail..
Also, by starting very specific for our own problem, it's easier to create a meaningful product that solves a real need. (Like startup!) I think it's easier to start specialized and then grow larger, than start too brood.
go there and make something too, instead of hoping for other people's souls...
[1]: http://www.washington.edu/alpine/
I mean a full blown browser of current generation abilities, but with the option of completely keyboard driven interaction. Concise input of small commands (navigation, data extraction, exploring and massaging of extracted data, data uploading etc.) that can be composed to form more complex interactions.
It should have full interoperability with the CLI, don't go re-inventing grep, sed etc. but instead stand on their shoulders by interoperating fluently with them. In practice i expect this means the "programer's browser" functions as a full blown terminal emulator too.
If it were a text editor (and it should be a competent one of those, but the web is more than a textual medium so some implementations should certainly offer richer functionality than plain text editing) then the net and its many protocols would be its filesystem.
It should be extensible, but only by 1 language. Competing programer's browsers could offer alternative extension languages as their differentiator.
It should be entirely open for extension, by that i mean more than plugins, i should be able to rip out core parts of it to be replaced with alternative implementations (A's needs won't match B's needs and so on).
It shouldn't go too far though, it shouldn't be a full blown operating system: why re-invent the wheel, reuse the thousands of man years effort in existing OS's. It should be multi platform.
We almost have the requisite component parts available now, who's going to get the ball rolling with the new wave of "programer's browsers"?
(Almost exactly what you describe is my current dream project, pieces designed, pieces roughed out, no part even remotely finished. The one I will get back to working on as soon as my startup exits and I have money and time. Or when it fails and I have time. You are not alone in wanting this.)
Why not have a packet-based interface for browser extentions AND automation? (like a database)
To add to your specifications: a "programer's web browser" should communicate with the user in a way which assumes that the user is knowledgeable. It should not use ridiculous metaphors like "this site could harm the computer! back to safety" or noob-oriented advice like "check the address for typing errors", but tell me things like "this URL is registered as a phishing site in such and such blacklist", "access to this site would violate an STS policy", "no DNS record for this domain, here is the result of the lookup", "no reply from IP A.B.C.D, here is a traceroute", etc.
My current choice of a keyboard-oriented browser is Firefox with the pentadactyl extension. It's not perfect, but better than anything else I've tried (including uzbl, which doesn't seem mature or well-documented enough).
Unfortunately, vmail doesn't seem to consider internationalization important at all. US users save a single press of the shift key when starring messages (,8 instead of ,*), but on a german keyboard, where the star is shift-3 instead of shift-8, the shift-less version of starring trashes the message instead. Not a typo I'm eager to make.
Problems like this are, sadly, way too common.
Two, I personally think that most international keyboards I have used have been any good at all for the tasks we face as programmers/hackers/developers. They put an emphasis on producing text, not code, and if you spend most of your day typing code and English anyway I can't see why we should "waste" precious keyboard real-estate.
I ditched my Swedish layout during my first year at university, went US-style and remapped the three keys that I needed to type "native" characters to Start-key combos. I haven't looked back since. It was also the point where I started touch-typing.
Mmm...yeah I think I'll pass but hey, good idea up to that point.
i am on mbp retina, ML, ruby 1.9.3, latest vim