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.)
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).
Why not have a packet-based interface for browser extentions AND automation? (like a database)
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
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.
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.
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.
Why on earth would you do that?
go there and make something too, instead of hoping for other people's souls...
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.
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`.
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
set smtp_url = "smtp://firstname.lastname@example.org:587/"
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.
If you're on Linux, it's also rather simple to store this in a keyring such as gnome-keyring (Seahorse).
Mmm...yeah I think I'll pass but hey, good idea up to that point.
Not a smartass question.