The editors Jeff Atwood is talking are editors we may expect to have in future. I believe he hadn't any existent one in mind, but maybe I'm wrong.
This being said, the tabs vs. spaces issue he's talking about is largely solved by some today's IDEs. Visual Studio, for example:
Adjusts spaces for you, making it easy to keep the same formatting in your code and never care about spaces. For example if you start typing:
if (! this.isDead )
this.Kill ( ) ;
it will fix it for you while you type:
Let you to reformat the document¹ with Ctrl+E → Ctrl+F (or Ctrl+Shift+F in Eclipse), if you still succeeded in messing up with spaces.
Enforces either tabs or spaces rule: if you open a document which contain both spaces and tabs, you will be asked if you want to transform tabs to spaces or spaces to tabs or keep everything as is.
Adjusts the indentation according to your settings, which makes it irrelevant to discuss the number of spaces per indentation (four vs. two for example) inside a team.
Another point is that today's IDEs are powerful enough to provide better visualization of code, making whitespace/tabs/indentation discussions less relevant in some circumstances. Instead of visualizing code as code, i.e. in plain text, you can view and manipulate² diagrams, graphs, etc. Visual Studio, for example:
Provide designers for a lot of stuff. You may for example create a Windows Form just through drag and drop, and never care about how the code is written and what indentation is used. Drag and drop development is also strongly encouraged in general by Microsoft and they are working hard on providing different means of creating code without writing it manually. Aside personal opinions (mine being particularly negative³), this drag and drop paradigm let you imagine what would be the next-next-generation editors and how they will abstract the tabs/spaces/indentation discussions⁴.
Let you create the basic structure with fully documented classes, interfaces, properties, empty (not implemented) methods, etc. by using class diagrams, without ever opening the source code itself. You must still go to code to actually write the bodies of methods or properties, but still, a lot of work can be done through class diagrams⁵.
Let generate code from UML⁶.
To conclude, with today IDEs, you don't even need to see the source code in some cases, since you may use alternative ways of viewing code. In this case, you don't have to care about indentation. And when you have to get back to the plain text source code, the IDE is clever enough to properly format the code as you write.
² The manipulation part is particularly important. If you can just view the code as data, but not change it, you still have all the issues related to whitespace, tabs and indentation. Older IDEs started to provide alternative means to visualize code, but it's only recently that it became popular to have a two ways relationship between a diagram (or other form of visualization) and the source code itself.
³ Mostly because auto-generated code is always too dirty, and is too limited in capabilities. For example, for the last ten years, each new WYSIWYG promised clean HTML and CSS, and still when you need clean code with CSS sprites and other advanced features, you will need to do the work by hand.
⁴ The code created by Windows Forms designer may not comply to StyleCop rules, but still, I never had to fix indentation for the auto-generated Windows Forms code.
⁵ The generated code violates magnificently lots of StyleCop rules, which means that the usefulness of class diagrams to generate code is rather limited if you care about style. Still, it takes away from you the care about whitespace, tabs and indentation.
⁶ I never tested this feature, because I don't have TFS. From what I remember, you can actually generate source code from some diagrams with VS2010 Ultimate + TFS. If I am wrong, feel free to edit my answer or adding a comment.