A vim interface for gmail: Vmail | Hacker News Reader

A vim interface for gmail: Vmail

danielchoi.com

145 pointsezl75 comments

When will we get a "programer's web browser"?

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"?

http://uzbl.org/

it's called uzbl

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.)

>It should be extensible, but only by 1 language. Competing programer's browsers could offer alternative extension languages as their differentiator.

Why not have a packet-based interface for browser extentions AND automation? (like a database)

There's Conkeror, which uses JavaScript: http://conkeror.org/

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).

Pentadactyl and Vimium if you want a "real browser" underneath too.

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).

One possible way is to use an extension called 'Vimium' with Google Chrome.

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!!!

Victory shall not be yours until your precious Vim has both Tetris and Towers of Hanoi. Emacs shall prevail.

What's emacs? Is emacs that editor released by Microsoft?

Then victory was ours circa 2004 ;)

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

Hmm . . . the battle may be closer than I thought. Vim still must be inferior somehow, right? :)

> 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.

Problems like this are, sadly, way too common.

So, it doesn't implement VIM's remapping commands?

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.

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?.

OSX has keychain which is designed for these scenarios.

http://www.dribin.org/dave/blog/archives/2006/01/16/keychain...

https://developer.apple.com/library/mac/#documentation/Secur...

Several Linux tools for this purpose have existed for a while as well - gnome-keyring (now seahorse)[1], KWallet, etc.

[1] https://wiki.archlinux.org/index.php/GNOME_Keyring

It came to my notice a few days ago that Gnome stored my Google Password in Gnome Keyring as simple text.

How did you come to this conclusion? If you've found a bug, please file a ticket.

Gnome keyring definitely uses encryption to store passwords; they take security pretty seriously: https://live.gnome.org/GnomeKeyring/SecurityPhilosophy

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.

For a nice gpg-encrypted password store, see "pass": http://zx2c4.com/projects/password-store/

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.

for vim fans, another option is mutt or alpine with vim as your editor. Both work with gmail.

Exactly, there is pine/mutt/alpine for that.

Yeah. This is cool and all, but it's kind of like modifying your cigarette lighter to carry passengers.

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.

Also nmh, though it can be complicated to set up (especially to set up well). Still meaning to put together a tutorial / description of my setup...

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.

> In the event of 2FA/MFA, I'm assuming one needs to generate an application-specific password and keep that in the .rc?

As far as I am aware, this is currently a limitation of any third-party client that connects to Gmail.

OAuth authentication for IMAP (via SASL): https://developers.google.com/google-apps/gmail/oauth_overvi...

I don't know if there are many clients that support it yet, though.

Same guy as ViTunes. <3 http://danielchoi.com/software/vitunes.html

I hope you at least felt some pain in your soul when you wrote a vim plugin for email that was gmail only.

Why on earth would you do that?

Welcome to Hacker News.

Well, consider GP's assessment as envy of those who use Gmail and therefore can benefit from this nice piece of software.

Yes, that's what I was told when I made similar comments about IE only websites years ago as well.

How short of a memory does this community have if they don't understand what comes after "embrace" and "extend"?

So the guy who wrote it uses gmail. There's no ulterior motive there. Just a person who uses gmail who wanted to use it in vim

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.

Gmail has several unique features that generic clients don't live up to.

Sometime more specialized/specific is better.

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.

I also assume this community understands what the word "FUD" means and how it relates to this post.

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...

It's just alpine [1] with a gmail interface (read: no annoying setup).

[1]: http://www.washington.edu/alpine/

This is quite similar to notmuch's vim plugin, if that makes you feel any better.

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`.

This is insane. Amazing, but insane.

Does this mean that vim is now officially finished?

Zawinski's Law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Is there a generalization of Zawinski's Law postulating that "Every program should expand until it can read itself"?

Wow, I love the idea. I have always wanted to manage my mail via terminal, but didn't want to set up Mutt or something similar.

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).

> 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).

If you're on Linux, it's also rather simple to store this in a keyring such as gnome-keyring (Seahorse).

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].

[1]http://lee-phillips.org/gmailRewriting/

Using Gmail in mutt directly over IMAP is sloooow. It's a bit more work to set up something like OfflineIMAP, fdm, or something else.

To me, here at work on a Windows machine, that looks like way too many dependencies for me. Looks cool, though.

With as much ram as people have on their machines these days, try virtualizing!

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.

[0]: http://vagrantup.com/

[1]: http://www.vagrantbox.es/

iawesome!thanks danielESC:wq

0~fti ^]2w~A!^]:x<RET>

>> vmail important from barackobama@whitehouse.gov

Mmm...yeah I think I'll pass but hey, good idea up to that point.

It would be great if this had integrated gpg signing and encryption, especially as firegpg doesn't work w/ gmail any more.

Perhaps it is a silly question, but what advantages does this offer over Gmail's rather robust set of keyboard shortcuts?

Why gmail and not email?

cool! plain curiosity: why gmail-only instead of imap?

Also by Dan: instantwatcher.com

Thanks to google killing free Google Apps accounts, I won't get a chance to use this. It's really sad because this is exactly what I was looking for.

How is this better than mutt with EDITOR=vim ?

Not a smartass question.

I honestly haven't used mutt in a while, but I used to have a lot of issues with it. I should give it another go.

If you're on OSX, my fork of homebrew has some patches to make threading et al work.

https://github.com/richo/homebrew/blob/master/Library/Formul...

Reply on news.ycombinator.com