Next on the long-awaited feature list: word wrap in Eclipse.
I can't say I even noticed line numbers on the page source in Chrome either. The formatting of source on a rendered page can be a bit messed up when the request is served, with tabbing and whitespace ended up all over the place, especially with loops. Then there's minified source if you're using someone else's code.
Most of the time it's easier to note the error, try and identify where it occurred, then find it in your editor. And with things like Chrome's developer console, sometimes using view-source is redundant when you have a DOM inspector and a number of ways to traverse it.
And even then, with a good linter you can avoid making basic mistakes like typos or missing parentheses or whatever, and in some cases even have undeclared variables or functions highlighted (Sublime Text 2 has one that in some places can appear quite fascist in how strict it enforces its policies, particularly with Python). At that point, usage of the browser for debugging code is most useful for capturing errors you couldn't reproduce elsewhere, and errors that only appear in minified code.
Not that I'm saying the browser tools aren't a great productivity boost. Because they obviously are. Just that I rarely find myself using the view source feature, really.
I was waiting for that feature for Eclipse too. But I switched to Sublime Text (http://www.sublimetext.com/2) and shudder when I think how many hours I wasted waiting for Eclipse to keep up with me.
I'm probably switching to Sublime, even though it doesn't autocomp. PHP. whatever, few more lookups in the manual are probably less time-consuming and stressful than an editor just blatantly crashing all over the place when just simply...inputting text
Although it'd be nice if Sublime came with autocomp out of the box (or at least an easier way to config it), the options are there. The blog I followed to set it up is http://urbangiraffe.com/2011/08/15/sublime-text-2-for-php/. It does make ST a bit more resource intensive than the vanilla version, but it is still loads lighter than Eclipse and also a small footprint on any modern machine.
Save yourself the time and skip the Soda UI part of the blog post
a colour picker is likely something the developers would simply never think to add in a product that is not specifically a web-development tool. you should write and suggest it.
Is it wrong to think badly of an editor where it's up to the developers to add a colour picker when the users want one? Emacs has a simple colour palette widget available at runtime.
it's a closed-source editor. the dreamweaver-style colour picker that the op is talking about is a gui widget that (unless the developers have gone out of their way to allow users to script the user interface itself with runtime bindings to every possible platform widget) pretty much has to be added into the core by a developer. emacs has gone out of its way to provide an extraordinary level of scriptability (more so than any other editor i know; i can only think of the old dos aurora that came close in the amount of functionality it pushed upwards into the extension-language level), and even they didn't allow for a real palette widget (if you read the wiki, the palette is hacked together from "zillions of tiny space characters, each in a different face", which is ingenious, but not exactly user-optimal).
I can't say I even noticed line numbers on the page source in Chrome either. The formatting of source on a rendered page can be a bit messed up when the request is served, with tabbing and whitespace ended up all over the place, especially with loops. Then there's minified source if you're using someone else's code.
Most of the time it's easier to note the error, try and identify where it occurred, then find it in your editor. And with things like Chrome's developer console, sometimes using view-source is redundant when you have a DOM inspector and a number of ways to traverse it.
And even then, with a good linter you can avoid making basic mistakes like typos or missing parentheses or whatever, and in some cases even have undeclared variables or functions highlighted (Sublime Text 2 has one that in some places can appear quite fascist in how strict it enforces its policies, particularly with Python). At that point, usage of the browser for debugging code is most useful for capturing errors you couldn't reproduce elsewhere, and errors that only appear in minified code.
Not that I'm saying the browser tools aren't a great productivity boost. Because they obviously are. Just that I rarely find myself using the view source feature, really.