Hacker News Reader

Comment by zdw | Hacker News Reader

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.

View on HN

I often write emails in Vim, then ggSHIFT-vSHIFT-g"+yALT-TAB CTRL-vTAB ENTER.

And that, my friend, is modern day integration between gVim and GMail on Windows.

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.

I'm not sure if you're saying that this shows the problem to be solved, or that it shows just how unsolved the problem is...

I've left that as an exercise for the reader.

Personally, I type the above sequence pretty much instantly, though, so... I don't mind: http://screencast.com/t/jw0LFrlBg

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.

Vimperator can do that. http://vimperator.org/help/vimperator/options.xhtml#%27edito...

"It's all text!", https://addons.mozilla.org/en-US/firefox/addon/its-all-text/

I like. It appears Google released a command line tool that integrates with its services: http://code.google.com/p/googlecl/

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.

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.

That is the actual point.

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.

I did, it was fine but I totally forgot about it.

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.

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.

Reply on news.ycombinator.com