The fundamental part of this isn't the CLI/GUI conflict, IMO, it's this paragraph:
For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool
The problem is people building standalone systems that aren't integrated with the whole. For example, most people's primary text editing environment doesn't carry over to their browser, or many GUI cases, their email program.
Solve this problem and the rest of the issues wouldn't be so severe.
Had you used mutt instead of Gmail, you would have simply used: SHIFT-zSHIFT-z. When you want to compose mail in one of these programs, it opens your specified text editor and uses the whatever text you enter as the contents of your message. It works a lot like the 'Intents' feature which has been Android has received so much praise for, only it's decades old.
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.
And it's awesome. When it came out, I immediately wrote half-a-dozen little things to work with it, including "whatson" -- an app that lets me do things like "whatson thursday" and have it show me what's on the calendar.
There is a Firefox extension that allows you to edit any text field with any text editor. I forget the name, but a quick Google search should reveal something.
Maybe you should give VMail a shot (http://danielchoi.com/software/vmail.html). I haven't tried it yet, but it looks really interesting for someone used to the Vim keyboard bindings.
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.
you've just shown the fail that is GUI.
alt tab and copy paste seriously?
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.
I suppose this is what Apple had in mind with their object-oriented, drag-and-drop philosophy for the Mac: a GUI which would allow people to pipe things visually with as much ease as possible, reaching a compromise between the UNIX philosophy and their notion of software design as making things "magic."
Right now, the most impressive achievements (IMO, and YMMV) in that arena come from the Plan 9 community, which is still a far cry from lay person's usage (partly because the Plan 9 community seems to pride itself—as a rule—for being a research OS community rather than the next blockbuster OS).
I like that plan 9 has stayed out of the chase for users, but I do think the multi-button mouse interaction model needs to be updated to leverage touch-sensitive surfaces and gesture commands.
For now, I just want to make the point that once you move to the command line, everything is trivially connected to everything else, and so you are mostly freed from being locked in to any particular type of tool
The problem is people building standalone systems that aren't integrated with the whole. For example, most people's primary text editing environment doesn't carry over to their browser, or many GUI cases, their email program.
Solve this problem and the rest of the issues wouldn't be so severe.