I really, really miss _why. He's one of the main reasons I ditched an awful career in the design industry and got back into UI development; I missed coding that much after reading _why.

He's out there somewhere. Along with Elvis.

"Eddie lives, somewhere in time" -- Dark Avenger

http://en.wikipedia.org/wiki/Dark_Avenger#Dark_Avenger.27s_v...

If you're on a mac and use Safari, QuickCursor (http://www.hogbaysoftware.com/products/quickcursor) is a nice free input manager that solves this problem. It lets you use a real text editor (Textmate, BBEdit, Smutron amongst others) in place of a text area. Pressing a hot key opens the text opens the text in your editor, and saving copies it back.

Sadly it doesn't yet work in Chrome, but the chrome team is working on it.

For firefox there is "It's all text!"

https://addons.mozilla.org/en-US/firefox/addon/4125/

(and mozex, which I used to use before that.)

Is there something like this for Chrome? It's the one thing I've missed making the switch from FF.

If you're using Safari, you can resize the textarea, search within it, scroll the textarea by mousing over it regardless of present field focus, and use emacs key combos like Ctrl-A, E, K, and Y without any additional software.

By editing your ~/Library/KeyBindings/DefaultKeyBinding.dict file you can set up a gigantic subset of emacs navigation keys (including almost-but-not-quite versions of C-k and C-y) in every Cocoa text widget on your computer, including Safari textareas.

Do a search for DefaultKeyBinding.dict, or just start with mine:

http://dl.dropbox.com/u/5431919/DefaultKeyBinding.dict

Ctrl + K is emacs? As far as I am aware it is available to every program on Unix through readline. See this wikipedia article: http://en.wikipedia.org/wiki/Control_key#Examples

It was originally an emacs binding. Then readline picked it up as part of its "emacs-style bindings". The name is not only cute, but also descriptive.

It was originally the terminal escape sequence for kill to end of line (ESC k) which is what emacs used to emit when you typed Ctrl-k.

Should be "ESC k was originally...", right?

Wow, I've been looking for something like that for awhile to help my CMS workflow.

I searched all over, but I guess I just couldn't adequately describe what I was looking for to Google.

Anything for Chrome on Linux?

There is Edit with Emacs extension - https://chrome.google.com/extensions/detail/ljobjlafonikaiip...

One happy user of Edit with Emacs for Chrome right here!

It should be possible to write an edit-server for other editors that work with Edit with Emacs, if you are that way inclined...

Vimperator does this, too.

The Bespin project has a cool bookmarklet, that replaces every textarea with an instance of Bespin.

Point of fact, on modern browsers textarea is better than notepad. You have spellcheck, and the standard range of move/delete by word commands, and undo.

And yet Chrome, presumably among the most modern of browsers, still doesn't have search/replace that works in a textarea.

Find works in Firefox.

I should point out the URL of the actual post was w3mIsMyAmbassadorToTheWikis.html, and w3m, a text-based browser, opens up your $EDITOR for you whenever you edit a textarea.

Out of sympathy for the Firefox sadface earlier in this thread:

https://addons.mozilla.org/en-US/firefox/addon/4125/

'Edit textareas using an external editor, because it's all text!'

I was thinking, "Hey, this writing style reminds me of _why! Has _why come out of retirement?" Then I scrolled up to see that it was an archive of his old site.

Hey they've already added the stretcher in the bottom right corner. That's something.

not in my firefox :(

well, I haven't really thought about it, but, yes, textarea is pretty ugly. and try to make it better (with weird wysiwyg javascript libs) can end up worse. hail _why.

    not in my firefox :(

It's coming in 4.0! They've added support for the CSS "resize" property, and set it to "both" by default. Just like WebKit.

Big fucking whoop. I think even IE progresses faster than FF these days.

Look at IE9. IE is going fast right now...

So yeah, but that's not actually a slam of FireFox, weirdly enough.

textarea was never meant to be an actual text editor, just a place to input multiple lines of text for forms

But, as an ironic twist, textareas are almost never sighted in the middle of structured input forms. Instead, you get abominations of denormalization like "Address Line 1/Address Line 2".

Every system your system will ever communicate with has individual fields like that. It's much easier to concatenate an address or name together from separate fields than to split them apart after the fact.

Of course—this isn't to bring back the whole semantics-of-names-and-addresses issue that HN discussed two months ago (http://news.ycombinator.com/item?id=1438472).

I was referring just to the street address part, though, which is almost always entirely freeform, or at least is up to complex and opaque rules that vary by city. This is what textareas are for: unstructured input of a string (not prose writing, but simply a string) that may require newlines in it.

Coming right after the street address field would, of course, be separate single-line input fields for the city, country, etc... but the street address itself should allow as many lines as you need.

> which is almost always entirely freeform, or at least is up to complex and opaque rules that vary by city.

And then, you get different countries. And shit hits the fan hard.

> I was referring just to the street address part

So was I. Every system my software communicates with has an "Address1" and "Address2" field. Ok, some only have an "Address" field. They don't except newlines and most of the time those fields are limited to 50, 100, or 256 characters.

My parent's address structure is:

House Name, Road, Village, Town, County, Country (if applicable) Post Code.

My address structure is:

Flat Number - Building, Road, City, Country, Post Code

Some multi-input address forms require that I enter both a city and a county, which in the case of Londoners means you end up putting London twice. The only important parts of the address (for most uses, including credit card processing) are recipient name, house/flat name/number (actually, not sure about this - it might not be necessary) and Post Code.

So why not just have explicit inputs for those fields which are always required, and allow a more fuzzy input for everything else in the form of a textarea? It also means you're more likely to be able to deal with addresses in countries that use slightly different systems.

From a credit card perspective, actually, you don't even need the house/flat name/number. As you can see easily on the basecamp paid signup page, all you need is:

First/Last name Card number Expiry Date Billing Zip

The rest of the fields on https://signup.37signals.com/basecamp/Plus/signup/new are unrelated to billing.

Worth noting that those extra billing fields like address and all that help cut down fraud (as well as signups...) so if your business is not b2b and relatively fraud-free, you probably should keep the extra fields for anti-fraud checks.

Not to mention, if you have those fields you'll pay less for the credit card transactions. I just recently added a bunch more address fields to a CC form to reduce the fees on transactions.

Does their town have many villages in it?

I've often dreamed of an embedded vi in my browser. Oh how many times I have hit <esc> and wiped out what I spent 15 minutes typing!

Vimperator?

6 years and it hasn't really changed.

We have a 4 way browser war, yet no one wants to improve the basic textarea. W T F

Hey, Chrome lets you expand it with a resizer on the corner. That's something

Actually, that's Webkit. Been in Safari for looooong before Chrome.

Firefox 4.0 will have that, it's working in the beta now.

If you've ever tried to build/work on a text area replacement, you'll know that it is an insanely difficult task. Highlighting and manipulating text sounds fairly rudimentary, but each version of each browser has enough bugs to keep a deveoper occupied for weeks with little to show. (I speek from experience.)

I think Google might have the right idea; the new version of gdocs completely ignores the browser's built-in (broken) selection and editing abilities and instead uses pure JavaScript listening for mouse and key events.

Chrome has the ability to resize textareas by click-dragging the lower-right corner: http://dl.dropbox.com/u/315/random_pics/chrome_textareas.png

I've got the Vimperator. It lets you use VIM inside Firefox. It will even open textareas inside VIM (Ctrl+i).

Downside: Ctrl+i doesn't work on the Mac. Anyway, it makes my working for the man a little less disgusting.

Works for me with MacVim: http://phaseportrait.blogspot.com/2008/12/making-macvim-work...

Thx a bunch. It's been some time since I last tried to get it to work, but now it magically does (thanks to your blogpost^^).

Anyway, I'm not using the -f flag. If I do, MacVim won't push the data into the textarea. It works with :x Cmd+q, though.

Thanks again. That will be a great timesaver in the years to come(;

oh, leave the poor text area alone.

I feel this poem has not been upvoted enough. If this does not reach 1000 upvotes in the next few days you are a disgrace to the interwebs!