Product demo videos don't usually hold my attention ... but I was riveted for the full 20 mins (full credit to both the product and Jeffry Way). Downloading the repo now.
The good: auto-refreshing preview of HTML page upon save
The bad: no auto-end-brackets or end quotes as one types (ironic, considering the editor is named Brackets)
I am sure that the talented Adobe engineers will make this editor a major contender for Sublime and Textmate in the future, but at this point, I think the stunning attribute in the post title is a bit link-baitish. I'm looking forward to watching the editor develop into a mature product!
Yes, you are correct! Egg on my face for not noticing the earlier mentions. Unfortunately for the army or Bracket promoters, substance really matters within the technical community. One can't market their way into product adoption with an inferior technical product in this community.
This has been around for a while now, I used it a few months ago, and while interesting it didn't do anything I don't already do with Sublime and other tools. Someday it may do those things more easily, but for now, I don't see any significant reason to switch.
I noticed that the Emmet extension added keyboard shortcuts like "Command+Up". But that's a standard OSX text entry navigation shortcut! Why would you do that?
It says right on the home page that it's maintained by Adobe & the github repos are all maintained by Adobe as well. Just curious, do you think Adobe has a bad reputation for making software that would make them want to dis-associate with the company?
Personally, I think Adobe has a bad reputation for making software. Flash, Dreamweaver and Acrobat comes to mind.
Flash - Difficult to work with (I know most beginners struggle with it).
Dreamweaver - Bloated software that generates weird HTML code.
Acrobat - Slow and bloated software. Can't a PDF reader be simpler ?
But as adrocknaphobia pointed out 'this isn't "Adobe Brackets", it's just "Brackets"'. Turns out there's no hiding after-all.
We aren't trying to hide Adobe involvement with Brackets, but it's very important to recognize that this isn't "Adobe Brackets", it's just "Brackets". This is a community driven project. Adobe is just the benefactor.
I think that putting Adobe's logo / name next to everything would overshadow all the work and contributions from the community.
Well, it certainly looks nice, but seems limited to mostly front-end web development work. I don't think Sublime and Textmate have anything to worry about for the foreseeable future.
SENSATIONALIST TITLE! This seems great for web dev, but Sublime is just killer for Python, I don't see this making any editor 'look out' if you spend most of your time in a backend language.
This looks interesting but what is more interesting to me is the brackets-shell, which looks to be a chromium shell for running an HTML/JS app as a native application. It looks to be very minimal and would just be fantastic for creating desktop apps. Every one of the existing solutions I've checked out so far all kinda suck in some way.
I hadn't realized that was working yet. I saw the repo for the shell itself is here https://github.com/adobe/brackets-shell - it seems almost like a lightweight version of AIR. Does anybody have any more information on this..?
How hard would it be for someone to build and IDE (with nice code browser, refactoring and all the smart stuff... like JetBrains products) on top of or incorporating an editor like Sublime or Textmate?
I'd pay an arm and leg for IDEA or PyCharm with Sublime as the text editor (or something else with multiple cursors and all the "shiny" editor stuff), and the ability to launch either the full IDE or just the editor and be able to share editor settings, depending on what I'm doing (eg. the IDE for browsing a huge codebase or just the editor for working on a small project)...
I can even think of a business idea: 1. make awesome open source editor (Sublime text with optional Vim keybindings is awesome enough for me) 2. build smart IDE on top of it (what I expect from an IDE are things that require "understanding the code", ie. lots of language specific features, refactoring and tools integration, nice looking tree code browser etc.) 3. profit!!! (imagine that you'll also profit from the evolution of the open-source editor and from the "complex" IDE features you develop, at the same time! and the "IDE haters" that will just use the editor would use or recommend the IDE whenever they would need to navigate an ugly codebase or recommend something to someone else)
Oh man I agree whole-heartedly. Let programs do what they're already good at. PyCharm is good at managing things and being a general IDE, and Sublime is fricken awesome at editing text.
Both try to dabble in eachother's realm, but the places where they shine should be inter-operable, not combative.
They're definitely working on it. I know the JetBrains folks are working very hard to integrate the editing systems of something like emacs / sublime into their IDE.
For now, what I do is use an external command that pipes out the buffer to Emacs and I use Emacs to slice and dice - then I just C-c # out of Emacs and switch back to PyCharm and keep on coding.
First of all, it's far, far easier to write a plugin adding the "shiny" editor stuff to an IntelliJ Platform-based IDE. As far as the editor features are concerned, the only stuff Sublime does that would be non-trivial to implement in IntelliJ-based IDEs is multiple cursors - but it's still far less work than building an engine for all the smart stuff.
Second, all the smart stuff has performance costs. As soon as you're building a complete model of the codebase and updating it in real time, you're losing all the low CPU/memory usage benefits of a plain text editor.
Really, the only aspect in which we fell the pain of not being native is font rendering on Linux (which has a crappy implementation in AWT and there's little we can do about it). Other than that, it's not a problem at all to integrate as many editor features as you like into a JetBrains IDE.
As for IDE support, I find Sublime text extended with a few key plugins to be just as good as a proper IDE when it comes to (in my case) front-end development; JS checking with JSHint, syntax highlighting for html/js/less, quick HTML using ZenCoding, andsoforth.
Care to enlighten me about how to enable or use this? (yes, it finally got column mode editing, but it is far from true multi-cursors, ctr+click in 3 different random places, even two of them on the same line and then move around, expand/contract selection to scope and do zen-coding tricks to them at the same time - yes, it's functionally equivalent to a refactor or a search and replace, but these alternatives break the "don't make me think!" philosophy of true multi-cursor editing that I consider the biggest advantage)
There's a Steve Yegge rant on that topic. It would be much easier to add first class support to a language if its implementation exported the internal data it creates from running/compiling the programs.
Without it, we are left with hacks, or lots of work for every new language, like Eclipse, which Yegge says has 3 Java compilers inside.
I stopped at "you can edit the editor's source code in HTML/JS/CSS" For me personally, I want the best native editor I can find that makes doing my job easier/simpler - I don't want an editor that I can tinker around with its source code and accidentally shoot myself in the foot.
Eventually everyone's editor search ends with vim, emacs or a management position. All these editors like Sublime Text 2, Chocolat, Light IDE, Cloud9, etc fail at very basic task: sticking around. They also fail at another task: being available everywhere.
If a new decent editor shows up, it wont be shiny, it wont grab headlines on HN with a fancily designed website, it will simply grow popular slowly, be added to package managers across platforms after withstanding the test of time. The test of more than one person or just a few developing it and then moving on to something else.
With vim and emacs you're guaranteed to not be wasting your time learning their arcane ways. Long after humans have left the Earth someone will be reprogramming a couple of launch tubes on their trans-stellar space vehicle with vim. They wont be using this fluff from Adobe.
Good grief. Emacs and VIM use has actually been going down since the 90s as a percentage of the developer community, and no one is predicting that they will regain market share.
And back to the original article, live programming and rich editing experiences is the future; emacs and VIM will go the way of the typewriter and x-terminal.
Parent did qualify that with "every developer I know." We tend to live in bubbles and don't see the big picture. Like "everyone I know programs in C++" is definitely true in some circles.
How many of us use x-terminals these days? I was referring to the hardware, not the emulation program. Perhaps parent lives in a world where they have a bunch of surplus DEC or HP X terminals and haven't moved on to PCs yet. Or perhaps parent just misunderstood my comment.
The Devs I know are predominantly on Windows, but they still use terminals. Some use CMD terminals on Windows, some use Putty on some remote Linux box. Some use Cygwin. And then there are a few Linux/OSX people who mostly use the graphical terminals native to their platform.
I use terminals, but not dumb terminals. I use terminal emulators on a modern OS on which I am able to install any editor I want. I have emacs/vim installed, but I use them maybe once every few months. There are better editors for what I do.
Emacs and VIM use has actually been going down since
the 90s as a percentage of the developer community
The quality of the developer community seems to have gone down since the 90s. Maybe the OP should have stated "Eventually every great developer's editor search ends with vim, emacs or a management position." At least, this has been my experience.
live programming and rich editing experiences is the future
I was previously assured that VPLs were the future.
>The quality of the developer community seems to have gone down since the 90s. Maybe the OP should have stated "Eventually every great developer's editor search ends with vim, emacs or a management position." At least, this has been my experience.
To quote Jack Churchill (during WII) "any officer who goes into action without his sword is improperly armed."
> I was previously assured that VPLs were the future.
They are. Its just that we are getting the VPL features that we want (live programming and rich editing experiences) in editors for our textual languages instead.
"The quality of the developer community seems to have gone down since the 90s."
Really? Can you back this up? As it seems to me the community is more engaged, productive and delivering high quality code. Yes, there's a lot more bad code as well, but that seems to be proportional to the increase in developers.
>> Emacs and VIM use has actually been going down since the 90s as a percentage of the developer community
My Google-Fu is coming up short, i can't corroborate this. Can you provide any links to data confirming this claim up?
I took a stab at getting some stats by searching stack overflow / server fault / super user for vim questions, emacs questions, textmate and sublime, vim comes out top by a long way, emacs next, the other 2 are a rounding error.
No surprise that there are lots of questions about VIM, it has a really sharp learning curve. You didn't include Visual Studio, Eclipse, IntelliJ, etc...which is a significant omission.
This is all informal and anecdotal, but I'll try to explain my reasoning/experience. In the mid/early 90s, you weren't really a great programmer unless you used a real text editor, so we would all eventually evolve into using Emacs (or VIM for the more daring). But then in 1997, Visual Studio got support for code completion (in VB), and Java and even C++ eventually followed. These language editors improved productivity for programming in those languages so much that it was hard to be competitive staying on Emacs. So perhaps most (~90%) of the Java/C#/C++ code written today is done with a well supported language aware editor (Eclipse, Visual Studio, JetBrains, ...).
Of course, if you are programming in a dynamic language, or a language with lousy tool support (C), then the language-aware editor doesn't really give you much (no static type system --> no static type feedback). There is a greater chance you are programming in Emacs (or VIM), but then you might not want to bother with the learning curve, or you might want something with a more modern non-ASCII UI, so maybe you are programming in Sublime or TextMate. There is nothing really wrong with this, you can be a great developer and prefer to avoid UX-archaic tooling, especially if you happen to also be a strong designer. There are strong trends away from text-based tools to visual tools, and I have no reason to believe that this isn't at play here.
The emacs community is vocal, and is particularly magnified in my field (systems/PL/PhD-level computer science) and demagnified at my place of employment (Microsoft, though keep in mind MSR has lots of Emacs/VIM users). But look at what the students prefer: they have no patience to learn these weapons from a more civilized time. They'll take whatever is the path of least resistance, and honestly who blames them!? Its not like they are losing much.
Why then, in circa 40 years, have we still not managed to find a better alternative?
I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems.
To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI.
With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite).
The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on.
So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon.
As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.
Emacs is only about 30 years old (VIM is only 20 yro), I guess you are talking about text-based interfaces in general?
I'm not going to completely disagree with you here. There are lots of time I've found a shell to be useful, but I've also changed my workflow to minimize the amount of time I spend there. Learning curve for shell is steep, not shallow, but I've gone through much of that 20 years ago. If there is an old tool I can use to do something, I'm all for it, but if its a new tool, I'll go for the visual one with the lower learning curve, because I'm quite busy. Still, nothing beats shell for composability and flexibility, I definitely lose something with my approach. I find lots of promise in projects like Mozilla's Ubiquity, but I have a feeling the next step are actually Siri-like dialogue systems (whether typed or spoken).
But we are talking about editors that are used to edit code. I'll argue that language aware editors (in Eclipse, Idea, VS) have already greatly surpassed VIM/Emacs in terms of productivity, but then you could argue back that VIM/Emacs could re-support these features (and people have crammed them in at some points, though these have failed to stick). So let's just assume equal footing for now, and evaluate the experience. Given that we have a good understanding of the development process now, I'll argue that an IDE with high-discoverability of its capabilities is easier to use than Emacs/VIM which require substantial training to master. Now what Emacs/VIM give you is lots of power, but I don't think most of us need that. Heck, I've even moved away from Emacs for Latex programming, where the "build project/view PDF" menu option in TeXniCenter is good enough for me.
I use Sublime on Linux/OS X/Windows. Please tell me more about how my editor of choice isn't available everywhere? If you're a sysop, or a devop and you spend a non-trivial amount of time remoted to strange and random servers then learning vim or emacs is a good choice. Unless its a Windows server.
There have been quite a number of requests for ARM support from the community already and the developers have, as far as I've seen, silently ignored them, which makes the situation even more annoying.
As a Linux user, as soon as you have SSH access to that strange server you can easily use gvfs to use sublime-text remotely, it's working great and is sooo simple to use..
It's probably not worth for a quick "let's change a setting in /etc/xyz" edit but it's worth it for everything else!
p.s.: i'm quit esure mac os x can do the same and in windows there is some third party app for remote ssh access/mounting.
I have a feeling that we might add Sublime to that list at some point. It is cross-platform and easily extensible. I hope it can survive long enough to accumulate enough plugins and developers and be open-sourced at some point.
I hope it can survive long enough to accumulate enough plugins
I don't think I'll ever understand why people would invest time (e.g., hundreds of hours over the course of years) extending closed source software over which they have so little control. So many people used TextMate until the development slowed. And now these same people seem to have jumped to Sublime Text. Did they port all the TextMate plugins they had written? Or did they not write any TextMate plugins to begin with? I'm guessing the latter because when I've browsed collections of config files at GitHub, the people who use closed source editors tend not to extend them, which is probably a wise choice.
I use vi, emacs, iawriter, and sublime text fairly simultaneously. I love the iCloud support in iawriter (for short notes, etc.). I love sublime text for beauty. I use vi for config files or when things are going badly on a system. I use emacs by default.
If vim actually supported other keyboard formats properly (rather than making the user redefine them from scratch) I would switch in a heartbeat. But until then, vim is useless to me.
I (and all the contributors to Brackets) respectfully disagree that a text editor released before the internet was available is the best we can do for web professionals.
We are really honored to be compared to Sublime and Textmate at this early stage. Those are fantastic text editors.
The purpose of the Brackets project isn't to replace those editors, but to inspire new ideas for web development tooling. It's simply a sandbox where the web development community can experiment with new ideas. Because it's written in JavaScript, HTML and CSS, everyone can get involved.
I saw this one a while back (a couple of weeks, I think). While it looked nice, I didn't "get it" - why would I use an editor that is severely limited (only HTML/CSS/JS) when there are other editors out there that supports pretty much everything?
Sure, you can "improve" (read: mess up) the editor by changing it's source code - but I still don't see the point. I'm using Sublime Text 2, with it's package manager. Everything I need is a few key presses away, and there's usually no need to restart the editor after installing something.
Also, I'd never use an editor that didn't support remote sync on save, version control, etc. (Managing component source code outside of the webroot makes it so much easier to handle in git.)
I doubt I'll be leaving vim for this anytime soon. More interesting would be if they could extract a framework for doing cross plattform desktop apps with html/css/js from this.
Here's the important link for anybody else who downloaded this and then thought "Damn, I fell for yet another link bait post for some halfassed unfinished edito--HEY, what a great font!!".
Do you mean that you weren't impressed with the font?
Or that there was something of value that I missed in this self-descriptive blog announcement of yet another pre-alpha release of an experimental text editor?
EDIT: Modern after-the-fact typo correction, be damned! Self-descriptive not 'self-deceptive'...
88 comments
[ 3.8 ms ] story [ 148 ms ] threadThe good: auto-refreshing preview of HTML page upon save
The bad: no auto-end-brackets or end quotes as one types (ironic, considering the editor is named Brackets)
I am sure that the talented Adobe engineers will make this editor a major contender for Sublime and Textmate in the future, but at this point, I think the stunning attribute in the post title is a bit link-baitish. I'm looking forward to watching the editor develop into a mature product!
Flash - Difficult to work with (I know most beginners struggle with it). Dreamweaver - Bloated software that generates weird HTML code. Acrobat - Slow and bloated software. Can't a PDF reader be simpler ?
But as adrocknaphobia pointed out 'this isn't "Adobe Brackets", it's just "Brackets"'. Turns out there's no hiding after-all.
The flipside is Twitter Bootstrap, which was never an "official" Twitter project.
https://medium.com/what-i-learned-building/b95033c270af
I think that putting Adobe's logo / name next to everything would overshadow all the work and contributions from the community.
-Adam Lehman Brackets Product Manager (at Adobe)
I hadn't realized that was working yet. I saw the repo for the shell itself is here https://github.com/adobe/brackets-shell - it seems almost like a lightweight version of AIR. Does anybody have any more information on this..?
http://youtu.be/HZkrlX7jJcg
I'd pay an arm and leg for IDEA or PyCharm with Sublime as the text editor (or something else with multiple cursors and all the "shiny" editor stuff), and the ability to launch either the full IDE or just the editor and be able to share editor settings, depending on what I'm doing (eg. the IDE for browsing a huge codebase or just the editor for working on a small project)...
I can even think of a business idea: 1. make awesome open source editor (Sublime text with optional Vim keybindings is awesome enough for me) 2. build smart IDE on top of it (what I expect from an IDE are things that require "understanding the code", ie. lots of language specific features, refactoring and tools integration, nice looking tree code browser etc.) 3. profit!!! (imagine that you'll also profit from the evolution of the open-source editor and from the "complex" IDE features you develop, at the same time! and the "IDE haters" that will just use the editor would use or recommend the IDE whenever they would need to navigate an ugly codebase or recommend something to someone else)
Both try to dabble in eachother's realm, but the places where they shine should be inter-operable, not combative.
I'll ping @intelliyole on twitter to respond.
https://twitter.com/mahmoudimus/status/279494119431217153
Update:
For now, what I do is use an external command that pipes out the buffer to Emacs and I use Emacs to slice and dice - then I just C-c # out of Emacs and switch back to PyCharm and keep on coding.
Second, all the smart stuff has performance costs. As soon as you're building a complete model of the codebase and updating it in real time, you're losing all the low CPU/memory usage benefits of a plain text editor.
Really, the only aspect in which we fell the pain of not being native is font rendering on Linux (which has a crappy implementation in AWT and there's little we can do about it). Other than that, it's not a problem at all to integrate as many editor features as you like into a JetBrains IDE.
IDEA supports multiple cursors, actually, ;).
As for IDE support, I find Sublime text extended with a few key plugins to be just as good as a proper IDE when it comes to (in my case) front-end development; JS checking with JSHint, syntax highlighting for html/js/less, quick HTML using ZenCoding, andsoforth.
Care to enlighten me about how to enable or use this? (yes, it finally got column mode editing, but it is far from true multi-cursors, ctr+click in 3 different random places, even two of them on the same line and then move around, expand/contract selection to scope and do zen-coding tricks to them at the same time - yes, it's functionally equivalent to a refactor or a search and replace, but these alternatives break the "don't make me think!" philosophy of true multi-cursor editing that I consider the biggest advantage)
Without it, we are left with hacks, or lots of work for every new language, like Eclipse, which Yegge says has 3 Java compilers inside.
If a new decent editor shows up, it wont be shiny, it wont grab headlines on HN with a fancily designed website, it will simply grow popular slowly, be added to package managers across platforms after withstanding the test of time. The test of more than one person or just a few developing it and then moving on to something else.
With vim and emacs you're guaranteed to not be wasting your time learning their arcane ways. Long after humans have left the Earth someone will be reprogramming a couple of launch tubes on their trans-stellar space vehicle with vim. They wont be using this fluff from Adobe.
The editors are different, yes, but both brilliant.
And back to the original article, live programming and rich editing experiences is the future; emacs and VIM will go the way of the typewriter and x-terminal.
How many of us use x-terminals these days? I was referring to the hardware, not the emulation program. Perhaps parent lives in a world where they have a bunch of surplus DEC or HP X terminals and haven't moved on to PCs yet. Or perhaps parent just misunderstood my comment.
To quote Jack Churchill (during WII) "any officer who goes into action without his sword is improperly armed."
> I was previously assured that VPLs were the future.
They are. Its just that we are getting the VPL features that we want (live programming and rich editing experiences) in editors for our textual languages instead.
Really? Can you back this up? As it seems to me the community is more engaged, productive and delivering high quality code. Yes, there's a lot more bad code as well, but that seems to be proportional to the increase in developers.
My Google-Fu is coming up short, i can't corroborate this. Can you provide any links to data confirming this claim up?
I took a stab at getting some stats by searching stack overflow / server fault / super user for vim questions, emacs questions, textmate and sublime, vim comes out top by a long way, emacs next, the other 2 are a rounding error.
This is all informal and anecdotal, but I'll try to explain my reasoning/experience. In the mid/early 90s, you weren't really a great programmer unless you used a real text editor, so we would all eventually evolve into using Emacs (or VIM for the more daring). But then in 1997, Visual Studio got support for code completion (in VB), and Java and even C++ eventually followed. These language editors improved productivity for programming in those languages so much that it was hard to be competitive staying on Emacs. So perhaps most (~90%) of the Java/C#/C++ code written today is done with a well supported language aware editor (Eclipse, Visual Studio, JetBrains, ...).
Of course, if you are programming in a dynamic language, or a language with lousy tool support (C), then the language-aware editor doesn't really give you much (no static type system --> no static type feedback). There is a greater chance you are programming in Emacs (or VIM), but then you might not want to bother with the learning curve, or you might want something with a more modern non-ASCII UI, so maybe you are programming in Sublime or TextMate. There is nothing really wrong with this, you can be a great developer and prefer to avoid UX-archaic tooling, especially if you happen to also be a strong designer. There are strong trends away from text-based tools to visual tools, and I have no reason to believe that this isn't at play here.
The emacs community is vocal, and is particularly magnified in my field (systems/PL/PhD-level computer science) and demagnified at my place of employment (Microsoft, though keep in mind MSR has lots of Emacs/VIM users). But look at what the students prefer: they have no patience to learn these weapons from a more civilized time. They'll take whatever is the path of least resistance, and honestly who blames them!? Its not like they are losing much.
Why then, in circa 40 years, have we still not managed to find a better alternative?
I can't help drawing parallels with windows / unix in the 90s and more so 00s. Yes, a point and click GUI is much easier to wing it with than a CLI, but, it doesn't deliver nearly as much power to the user as a proper CLI with a small number of reusable tools that can be composed to solve many problems.
To give a concrete example, if the GUI designer of your chosen deployment tool didn't imagine anyone would want to filter nodes to target a deployment by a substring of the node name, then you are out of luck - resorting to hacking your hosts file on windows to null route all the hosts you don't want to hit, followed by deploying to all nodes from the brain dead GUI.
With a proper CLI, only your imagination reduces your ability to solve whatever business problem (and they are infinite).
The net result of this shallow learning curve? We got a lot of people who refused to learn how to manage a network, winging it and being employed in positions of significance - average corp. with hopelessly leaky data safeguards and so on.
So back to the ux archaic editor, nothing has surpassed it despite 40 years of continual focus. While I wouldn't dismiss attempts to improve it out of hand (I'm a paid up customer of ST2), I also wouldn't count on an revolution relegating vim to the history books anytime soon.
As for VS, Idea etc. they are merely a chapter 11 filing away from being forgotten. Eclipse could live on. Who knows.
I'm not going to completely disagree with you here. There are lots of time I've found a shell to be useful, but I've also changed my workflow to minimize the amount of time I spend there. Learning curve for shell is steep, not shallow, but I've gone through much of that 20 years ago. If there is an old tool I can use to do something, I'm all for it, but if its a new tool, I'll go for the visual one with the lower learning curve, because I'm quite busy. Still, nothing beats shell for composability and flexibility, I definitely lose something with my approach. I find lots of promise in projects like Mozilla's Ubiquity, but I have a feeling the next step are actually Siri-like dialogue systems (whether typed or spoken).
But we are talking about editors that are used to edit code. I'll argue that language aware editors (in Eclipse, Idea, VS) have already greatly surpassed VIM/Emacs in terms of productivity, but then you could argue back that VIM/Emacs could re-support these features (and people have crammed them in at some points, though these have failed to stick). So let's just assume equal footing for now, and evaluate the experience. Given that we have a good understanding of the development process now, I'll argue that an IDE with high-discoverability of its capabilities is easier to use than Emacs/VIM which require substantial training to master. Now what Emacs/VIM give you is lots of power, but I don't think most of us need that. Heck, I've even moved away from Emacs for Latex programming, where the "build project/view PDF" menu option in TeXniCenter is good enough for me.
It's probably not worth for a quick "let's change a setting in /etc/xyz" edit but it's worth it for everything else!
p.s.: i'm quit esure mac os x can do the same and in windows there is some third party app for remote ssh access/mounting.
But that I'm an Emacs guy.
I respect the wit (a lot), but I'm not sure this the opinion you profess is really true of everyone in general.
I can type plenty fast and my muscle memory is kinda crazy insane... Notepad++ gets me everywhere I ever need to go.
I spend most of my time trying to write the least amount of code possible rather than worrying too much about what editor I use for writing my code.
Not trying to argue. Whatever floats your boat etc.
So my fingers don't look as busy as when using Vim, but I'm actually doing the same thing and postponing RSI.
I recognize that anecdotes != winning PowerBall tickets, but I have never in my life met a user of Chocolat, Light IDE, or Cloud9.
But pretty much every Mac or Windows developer I know has ST2 at least installed (Linux, not so much (at least not yet), although it is available).
We are really honored to be compared to Sublime and Textmate at this early stage. Those are fantastic text editors.
The purpose of the Brackets project isn't to replace those editors, but to inspire new ideas for web development tooling. It's simply a sandbox where the web development community can experiment with new ideas. Because it's written in JavaScript, HTML and CSS, everyone can get involved.
-Adam Lehman Brackets Product Manager
Sure, you can "improve" (read: mess up) the editor by changing it's source code - but I still don't see the point. I'm using Sublime Text 2, with it's package manager. Everything I need is a few key presses away, and there's usually no need to restart the editor after installing something.
Also, I'd never use an editor that didn't support remote sync on save, version control, etc. (Managing component source code outside of the webroot makes it so much easier to handle in git.)
Vim. That is all.
https://github.com/adobe/Source-Code-Pro/downloads
Do you mean that you weren't impressed with the font?
Or that there was something of value that I missed in this self-descriptive blog announcement of yet another pre-alpha release of an experimental text editor?
EDIT: Modern after-the-fact typo correction, be damned! Self-descriptive not 'self-deceptive'...