I really can't wait for this to be released. I am a little pessimistic about the Vim mode. There are countless 80 or 90% complete Vim modes in various modern editors. But the absence of a truly native feeling Vim (that last 10%) is a deal breaker for many. I'd rather see more editor developers spend time finding a solution that provides a truly authentic Vim mode instead of spending countless hours merely approaching 90% compatibility. For the people who you're selling on that Vim mode (the people who would care that your editor provides it) 90% isn't good enough. There are other ways to integrate Vim modes in your editor such as using the (inappropriately named) "Netbeans interface" which actually allows Vim to run in the background while you integrate your UI on top of it across a serializable bridge. This allows a perfect recreation of Vim while letting you customize the application experience on top of it.
Aside from that approach, there are a few faithful Vim recreations that I've discovered out of the dozens that I've tried.
What really bugs me are Vim modes that don't allow you to easily add new keybindings that abstract combinations of keystrokes, i.e. map <key> <keys>. For instance, I love to bind "s" to "go into insert mode, insert one character, exit insert mode". I feel crippled without this binding, but making it happen in Sublime 3 with Vintageous is daunting. It involves understanding the Sublime API and constructing some complex block of configuration code with way too many commas and brackets (JSON sucks). In Vim, configuration is a bunch of one-liners and I love that.
I’ve used Evil in Emacs with http://orgmode.org/, after having learned Vim. I’d say Evil is another great, thorough emulation of Vim. It includes even relatively-obscure features like visual block mode, R, K, v_o, :%!sort, ^W window split/switch/close commands, and Vim’s tree undo model.
My only problems with Evil are where Emacs or Emacs plugins’ bindings conflict with Vim bindings, such as v_^G (that is, Ctrl-G in Visual mode) meaning “Quit” instead of “Switch to Select Mode”. Those conflicts aren’t really Evil’s fault – they’re inevitable when combining third-party plugins that don’t explicitly support Evil – but they can be annoying.
I’d say you’re not missing much with Evil that would be in Vim. I suppose you’re mainly missing Vim’s large ecosystem of plugins that are made to work with Vim keybindings and Vim’s editing model – though I see that surround.vim has been ported (https://github.com/timcharper/evil-surround). Plus Vim wouldn’t have Evil’s and Emacs’ keyboard conflicts, of course.
I recall this most recent emacs effort the best of all the previous attempts (Viper etc). I believe there was one thing I couldn't fix:
When in command mode (such as when you type :e etc), hitting back space stops at the last deletion. In Vim, if you continue pressing backspace, the editor cursor starts moving back (as if you're pressing `h` in normal mode). (Did you figure out how to fix this?)
It's the little things like this that have become ingrained in our muscle memory over the course of more than a decade.
I do agree that emacs' scripting environment is better than Vim Script.
I don’t understand your backspace problem. In all of the following cases, Vim 7.3 and Emacs 24 with Evil act the same:
In Command-line mode (by typing `:`), when there is text after ‘:’ and before the cursor, typing Backspace deletes one character behind the cursor. In Command-line mode, if there is no text left but ‘:’, it exits Command-line mode, changing to Normal mode. Emacs displays Quit in this case, while Vim just exits silently. If I press Backspace in Normal mode while the cursor in the middle of a line, the cursor moves back one character as if you pressed `h`.
I did just notice an inconsistency with Backspace, but it doesn’t sound like what you’re talking about: if you press Backspace in Normal mode while the cursor is at the leftmost column, the cursor wraps to the previous line in Vim, but stays in the same place in Emacs. The cause of that behavior in Vim is the 'whichwrap' option’s value containing “b”. Evil has a rough equivalent to that option in evil-cross-lines (a boolean), but I don’t know if it has an equivalent that lets you selectively enable wrapping only for Backspace and Space. https://bitbucket.org/lyro/evil/issue/247/evil-invert-char-s... implies that there was no exact equivalent as of Febraury 2013.
I'm not an Evil expert, but my experience were that the conflicts with existing Emacs keybindings made things more frustrating. As a vim user interested in Emacs I'm trying to avoid Evil and other "90%" vim emulations from now on as well.
Vim does not support graphical user elements, and is built around the unfamiliar language Vimscript. Those drawbacks are pretty baked into Vim and would be hard to change (though someone is trying to: https://www.bountysource.com/fundraisers/539-neovim-first-it...). Many other editors don’t have these drawbacks, allowing them to support features such as these:
• a graphical file tree browser (with icons, not restricted to ASCII art like NERDTree)
• proportional-width fonts
• a zoomed-out-code mini-map scroll bar
• Plugins written in more mainstream, cleaner languages than Vimscript. Vim does have a plugin interface for some other languages such as Python, but some OSs’ provided Vim installations don’t support those languages, and it’s hard to get a version of Vim with support.
It's happening as we speak (since a few days, based on the crowdfunding campaign). It seems like there's quite a bit of people (volunteers and would-be volunteers) participating already. Voting about the preferred voting style is about to end:
React is defined by its declarative nature (for ease of coding) and virtual DOM (for performance). Not sure if SpacePen does the same, but at a first glance of the documentation I'm not seeing anything along those lines…
I love the edit markers in the last screenshot. But too skeptical about the performance of a text editor running in webkit. All of my experiences writing text online have been bad. So the jump into using webkit for an entire dev environment fills me with dread.
Brackets[1] is a decent programmer's text editor developed by Adobe and using WebKit. It works fine. The performance and polish of web editor components like CodeMirror has come on a long way in the past couple of years.
Have you used LightTable? It's quite fast as the editor. I'm sure Atom is similarly fast. It doesn't run in the browser; it just uses WebKit as the engine.
The nice thing about Vim mode is that it glosses over latency by making simple edits take fewer keystrokes. It's sort of why vi was invented.
In the words of Bill Joy himself:
> ... you've got to remember that I was trying to make it usable over a 300 baud modem. That's also the reason you have all these funny commands. It just barely worked to use a screen editor over a modem. It was just barely fast enough. A 1200 baud modem was an upgrade. 1200 baud now is pretty slow.
> 9600 baud is faster than you can read. 1200 baud is way
slower. So the editor was optimized so that you could edit
and feel productive when it was painting slower than you
could think. Now that computers are so much faster than you
can think, nobody understands this anymore.
Yeah, as the create of GitGutter for ST, my first thought was, cool if I switch to this I can write GitGutter in CoffeeScript. Then I thought, being Github, they would probably bake that in.
To put "often" in context, I raised a Github issue on it today which was resolved within a few hours, it's improving incredibly quickly (and it's already awesome).
I thought CodeBox was using the ACE editor as part of their system like Cloud9. And I believe Orion and Codenvy (my company) use CodeMirror. Looking forward to trying out Atom. I can see many advantages already of it as an editor.
Considering that ST is barely ever worked on, not really. Maybe a few spouts. I love sublime, if it wasn't for the awesome plugins I probably would have ditched it. :)
FYI, it's not WebKit but Chromium I'm betting, based on the crash reporting. If you want an idea of performance, Edge Code from Adobe will provide an answer. Oh and there's a welcome repo with an IRC channel listed. Atom.io just says "nope" for me but is likely its future home.
> it looks like this is a GitHub-aware/integrated text editor that targets both desktop (Mac, at least) and web
I can confirm, from looking at the code.
It uses CSS / LESS for highlighting, and CoffeeScript for client-side programming (eg, the fuzzy completion[0], or the autocompletion).
The surprising part is that the editor doesn't seem to be a fork of either Ace or CodeMirror, the two big guys in the field. The highlighters (ie, syntax files) are in CSON. Ace is probably the closest, but it uses a completely different structure[2].
A negative impact of that is the low number of syntax files. However, there seems to be a 1-to-1 equivalence to tmLanguage (TextMate) syntax files[3].
Interesting. The whole Sublime Text theory takes another buff.
The tmLanguage syntaxing, while limiting, is still pretty damn easy to create and edit, thus I approve. The idea that you have to learn a new way to build new syntaxes for every editor out there is a big issue for me as if you're going to be on the edge using new templating syntaxes, flavors of other languages etc. you just have to be able to fiddle with syntax highlighting, especially with new editors with poor/incomplete syntaxes and few user created syntaxes to fill the holes.
IntelliJ is pretty nice on this point. You write a PEG-style parser and get a full AST. It is a lot of work, but the payoff is pretty nice and they have a lot of solid tooling to help you out.
Don't feel bad, there's nothing worse (for editing) than using a half baked version of vim in another editor. The best of implementations will leave you with an uncanny valley feeling of disgust. I'd rather use a non-modal editor, all or nothing.
Funny, I'm just the opposite. I'd rather have the basics than nothing.
Mostly I've used VsVim and Viemu. They're both pretty decent. (Viemu is better though, it's got everything I normally use except for :norm. VsVim is missing column mode and the vap doesn't work.)
I've built a suite of useful shortcuts that only work with my vimrc, which isn't a problem since installing my config from my github repo is a 3 step process, but when I'm running in some "vim-mode" editor I find myself tripping up on not having these things that I've committed to muscle memory and it ends up killing my productivity. At least if I know the editor is always in insert mode I can adjust with the occasional :w here.
You can try this out https://atom.io/packages/atomic-emacs. It's not yet complete, and I'm still working on it, but I think it's a start. Feature requests are welcome :)
And it's totally gonna be awesome. I'm fairly confident they built it around node-webkit or another wrapper, perhaps in browser, I'm not sure.
What's important is that it's a text editor on top of web technologies. I was poking around doing the same a couple months back, brackets has been doing it for even longer. It's honestly sorely needed because of the amount of expression one can put into due to it's technological stack. An open, compile-less, hot-reloading editor sounds like a dream coming true.
I'm excited for it.
It also appears to be built around react, so that's really cool as well. And the code is simply great.
> An open, compile-less, hot-reloading editor sounds like a dream coming true.
You're talking about Emacs, right?
This actually seems really exciting, and I'll give it a whirl when and if I can. It's just funny to see people (the Light Table fans as well) rediscover what Emacs users already knew - modifying your editor in-place is really awesome.
> It's just funny to see people (the Light Table fans as well) rediscover what Emacs users already knew
Since many of the Light Table fans either use or have used Emacs, I would say that it is more of a relief to have something that takes the Emacs concepts and tries to modernize, adapt, or polish them. It might also be good to mention that the Light Table team chose a "usable editor first" strategy to build a user base, before attempting the concepts they demoed early on in development. So, we will see if it ends up mimicking Emacs or, perhaps, something different.
You hit the nail on the head there: "tries to modernize, adapt, or polish them". There's a lot we can do with the stack, we've got websockets (pair programming anyone?), workers, sql, and more baked into browsers. I'm not saying an editor cant do those things, but I think the level of entry and collaboration are totally different outside a web stack.
Over the last 18 years, I've tried to figure Emacs out a few times, but it always ends up baffling me. It may be as powerful as you say, but given how obtuse I am (or perhaps how terrible Emacs is), I'll never know.
It took me a good 15 years before I started using Emacs a few months ago.
What made it work was (a) learning how to tweak the configuration to suit me, (b) learning Emacs jargon equivalents (chiefly: selection => region, cursor => point, open => find, file => buffer, pane => window) and (c) already knowing enough lisp to be able to tweak configuration further than simple variables and modes.
Then what really made it work was finding out about package repositories.
Emacs, when I first started out, didn't understand the arrow keys properly on my terminal, and required you to learn all the C-n, C-p, C-f, C-b etc. to move around. It also didn't have transient mark mode. But it can do all these things now (although I still have terminal configuration files to map function keys in Cygwin, Rxvt etc. because I mostly work in the terminal), all it really took was a Sunday afternoon researching settings, key bindings and modes, before it was almost as usable as any GUI editor.
Emacs is awesome. I'm sorry I didn't learn it sooner. I've gone through several generations of IDEs and programmer's editors that have come and gone in the past 20+ years. I could have been using Emacs all that time and increasing my knowledge and library.
It is, however, still weak with languages that heavily rely on IDE support, like Java and C#. emacs-eclim and other hacks aren't quite enough to make up for it. Although I still have an emacs session open on every Eclipse project because helm-git-grep is way too good to not use; and also it's better for certain text editing. I had a big aha moment when I found out that M-/ also works in Eclipse!
> It is, however, still weak with languages that heavily rely on IDE support, like Java and C#
Which I see as a weakness of those languages -- not a weakness of Emacs (or Vim, or any other Not-The-Walled-Garden-IDE). I think needing an IDE to be productive is a kind of "language smell".
I do appreciate that some of us don't have a choice but to use them, and that they have good points -- just not this.
Well, the strengths of languages like C# and Java are extensive libraries along with static typing and the code completion that enables. Object orientation also helps with code completion, because the you normally have the noun to hand in a local or a field before trying the operation.
Java does have a fashion for verbose identifiers, and C# has picked up a little bit of it, although the ceremony is less in C#. Ceremony can be macro'd away, but verbose identifiers are more problematic.
I'd also argue that the scope and complexity of big Java apps is often larger and broader than most C++ apps: more libraries used, and at a higher level of abstraction. When you dance across the surface of many different libraries, good code completion makes your life easier. That is, the chief problem code completion solves is not intrinsic to any given language, but rather the absolute number of symbols used.
When coding languages like Ruby, I rely heavily on the interactive console (Pry for Ruby) in order to get the moral equivalent of code completion.
This is even greater! Text editors are not about code only, you know. Remember this¹? Released less than two weeks ago: Github now renders prose diffs. Why?
What if Github is going for an Office (or at least a Word) replacement? Author your blog, thesis, paper, novel, whatever, in a single polyvalent multiplatform editor, with the auto-versioned source stored in the cloud (Github’s), then use it as a feed for your blog, newspaper production flow, or other automated publishing environment…
Hope the fine people at the likes of Draftin.com, Etherpad.org, Penflip.com, Prose.io, et many alii, will survive this. The much acclaimed Editorially.com closed its doors already. Maybe the visionary folks at Substance.io might consider to start negotiating an acquihire.
I feel both exhilarated and a bit jealous: I know for sure I’ll need to put another side-project of mine down.
Move over, I'm hoping for a service-optional editor, also run locally hopefully. I don't mind adding cloud features, but not solely based on, as it creates the same problems closed source editors have.
Looks interesting! I saw a commit 24 minutes ago for "Prepare 0.7.0 release" in the Welcome package, so it looks like they're planning to go public shortly.
Check out Codebox.io, another open source web ide. I've been comparing the two from a self-hosted standpoint. c9 definitely has the more polished interface (for instance, the ability to resize any pain), but codebox doesn't seem to limit any features on the self-hosted version. It just seems to work better.
I only got my self-hosted version running last night and couldn't seem to spot a "chat" option (had two different browsers open) but for any file that was open by two people, you got to see who was editing what within the file.
When I was running c9, I couldn't even get the console to display. I found a plethora of issues in their github issue tracker of other people with the same problem, as well as code suggestions to fix it, but virtually no response on any issue from the c9 people.
I reported an issue I was having with codebox on their tracker. First I thought it was a bug, then I found a workaround (set the USER environment variable before starting codebox). I reported that on the issue, suggesting a documentation update, and within an hour, they had committed new code that made the workaround unnecessary.
So for self-hosted, I think codebox has the more stable and actively developed codebase while c9's open-source version is more of an afterthought. But I do admit that c9's hosted service is much nicer than codebox's hosted service.
> All of the competition can only be good for us developers.
Competition isn't a panacea. All this means is that we get to choose from dozens of half-baked options instead of a small number of ones that have each gotten a lot of effort poured into them.
A little more cooperation would be nice, but editors are one of those things where everyone seems to want to try their hand at it before getting bored and wandering off.
See also: build systems, programming languages, games.
Yeah. This whole thing (an endless supply of stream-of-consciousness style blog posts about one new editor after the other - first that one where the dev sold unlimited upgrades and then didn't bother to release a new version (can't remember the name), this Sublime Text thing, lighting table or whatever it's called, and for example the bruha around this 'neovim' fad) is like watching a bunch of ricers argue over whether a red spoiler will make your Acura go faster than a blue spoiler, and doing that from your 2013 7-series BMW and wondering 'what are these people talking about'.
Add LIVEditor [http://liveditor.com], although it's single-purpose is for css, html and js only. It uses Webkit too, but for live preview of css and html changes only, like the real-time effects you can see with Firebug or Dev Tools.
Thanks. The homepage was using the <video> html5 tag, looks like some browsers don't support them well, I finally decided and have changed to youtube video instead...
At GitHub, we’re building the text editor we’ve always wanted: hackable to the core, but approachable on the first day without ever touching a config file. We can’t wait to see what you build with it.
Am I the only one who finds it hard to believe this has indeed been leaked and is not just a marketing strategy from Github? The repos are not even private.
Leak is the wrong term, and it’s doubtfully a deliberate marketing move either. More like, “suddenly being noticed because a bunch of GitHubbers followed the @AtomEditor account on Twitter”.
Also, despite the plethora of repositories, the actual editor is not available. It could be many of the public repos are public so they can be installed using their Atom Package Manager, which would likely have to jump through hoops if they were private.
That's correct, I'm the one who first found the project and I wouldn't call it a "leak". The site is live (domain registered by GH), the twitter account is live, the repo is full, the release is probably imminent.
I'm in this camp. Have you ever been to a talk given by Scott Chacon? He demos git on Github's internal repos. It's clear that there's little value placed on keeping a feature under wraps before it comes out over there.
And rightly so! Marked indeed is a fine 𝗠⬇ parser!
How would you compare your approach to e.g. markdown-js¹, mdown-parse-pegjs², or text.js³ (which are based on PEG parsing)?
I would like to elaborate a bit on the specific differences/benefits between the many MD parsers. (I’m maintaining an inventory of Markdown resources in a repo on Github.⁴)
Speed was originally marked's top priority. I would say marked's approach takes advantage of the fact that v8 generates _extremely_ fast machine code for regexes. This is just something I discovered through many endless nights of benchmarking the entire markdown test suite.
Using complex regexes for the lexemes seems like a stupid idea to most people, but it allowed me to optimize marked like crazy, so much so that it beat discount(written in c) in benchmark times (It might be a little bit slower now due to the latest features. I decided to ignore speed for a while to focus on features - will get back to optimization eventually).
The downside of all of this: marked loses some extensibility, however, we implement as much extensibility as possible by exposing the token stream and renderer.
Accuracy and sanity quickly became marked's next top priority. There's a certain threshold of accuracy you want in a markdown engine (you don't want it to be too accurate because markdown.pl had a lot of bizarre behavior). That's a different story.
I'll keep this as short as possible, but that's not easy.
Speed: It's relatively slow (but fortunately faster than markdown.js at the very least).
Quality: It carries with it a bunch of nonsensical quirks. Some of these quirks are inherited from the original markdown, some are unique to showdown. (I feel like I could write a treatise on list behavior alone, and how ridiculously showdown and markdown.pl handle them). It's not what people are accustomed to/find intuitive today. Here's a few problems (with showdown, as well as other engines) presented in a more tangible way: https://github.com/chjj/marked/blob/master/doc/broken.md
Code quality and maintenance: Showdown is a line-for-line port of Markdown.pl. As you can guess, this is not ideal, especially when you consider that the original markdown was written extremely awkwardly - it's essentially a pile of regexes doing global replaces on a single string to produce the output. This is _extremely_ confusing and messy to those who are not familiar with a code, and the original author of showdown, as far as I know, no longer maintains the project.
the world needs a new infrastructure for thoughtful documents,
including a new text-editor. but from the look of it thus far,
this github thing lacks _simplicity,_ by an order of magnitude.
Thanks for the credits :) I'm indeed the person who figured out what GH was working on based on Twitter's notifications letting me know that a bunch of my GitHub friends suddenly followed the atom.io twitter account. From there it was easy to link things together.
What sets this apart from the other WebKit-based text editors, LightTable and Brackets? In general it seems like there's been an explosion of new text editors with this style since TextMate went into hibernation around 2008. It's great to have options, but there's lots of these TextMate clones now.
LightTable is different then most editors by design, in that it tries to reproduce Bret Victor's idea on "the future of programming".
Brackets is really neat, it just attempts to be a good editor, it has some unique features like toggling css inline from an html file for example and other jazz.
So Atom isn't something that's really set apart from webkit-based editor, but I don't think that's what's important here. It's the potential the stack offers us.
There's also not as much competition in this area, but it's sorely needed. I feel vim, emacs, textmate, sublime and most the editors are generally closed source or have huge code bases, and they are hampering the process of innovation by creating walled gardens or creating a barrier to entry. With a editor based on web technologies things really open up a lot.
Think about an editor where you can write a feature, pass the tests, and have a hot reload. No compiling, no closed source or plugin system. Just simple coffeescript/javascript some html and css. And bam, you've rewritten your status bar without effecting work in progress. That's something an editor should give us.
As a side note, it seems like Vim will get a little better soon in terms of its barrier to modifying it and creating plugins. Someone has started a credible project to create a fork, Neovim, which will be easier to modify and extend: https://www.bountysource.com/fundraisers/539-neovim-first-it....
You seem a little harsh on Emacs, but I'm with you in general. (To be fair, Emacs is an enormous pain to get into, has a bunch of legacy cruft, has odd terminology that is difficult to learn, and has a terrible default config. To be fair, Emacs is also leagues ahead of its competitors [referring to Light Table, Brackets, Sublime, and this] in terms of plugins and maturity).
I really just want something with Emacs' principles that doesn't have as much cruft and runs on the web. Light Table seems to be the best bet so far, but this looks interesting as well.
I'd love to see a good pair-programming environment. Floobits has been having a good crack at this but has the disadvantage of having to co-ordinate both the git commits and the workspace edits on multiple remote machines. GitHub won't have this problem so I expect that pair programming remotely is about to get a ton easier.
True, but until Sublime started eating his lunch, TM2 was being developed so quiet and slowly that a bunch of people thought it was vaporware. I believe that's what the OP meant by "in hibernation".
What sets it apart? We will find out when it is released. I doubt GitHub would waste there time building a TextMate clone unless they have something intriguing or new to bring to the table.
For one thing though, we can probably expect incredible GitHub integration.
It could also mean they are going the Cloud 9 route (unlimited free public editing, limited free private projects) for the web version, which would essentialy be the same as their current subscription model, while still open-sourcing the editor itself.
It also has the line: "At GitHub, we’re building the text editor we’ve always wanted: hackable to the core, but approachable on the first day without ever touching a config file. We can’t wait to see what you build with it."
Me too! I'm a big Sublime Text guy, right, but simply put sublime is lacking, especially in UI flexibility and advanced IDE features, like intelligent autocomplete, type checking etc.
If this thing delivers sublime-tier quality code editing in the browser and desktop AND commands a big enough community to allow for even more features (due to being open source), perhaps even IDE tier features... Sign me the fuck up. I'm tired of using closed source crap, patiently waiting for the dev to get off his ass and build more API functionality.
A text editor in a browser? There seems a lot of excitement about it but I can't work out why - can anyone explain? I'm not trying to be argumentative; I really am curious!
It's for editing text and there appears to be massive excitement about it....?
Considering I am currently working on a ChromeBook, yeah it is is interesting for a class of users.
There are some well known web IDEs like C9 etc that don't really appeal to me and there is a Chrome app called Caret that look very Sublime Text like but lacks plugins. I am happily working with vim and tmux (although I have Sublime Text in a chroot if I felt the need) but Web IDEs have potential.
I had a play with something called godev and it had support for godoc, go-oracle, godef, fmt etc as well as all the usuals like syntax highlighting etc based on Eclipse Orion. It lacked a lot of editor features though and things like git integration so it wasn't really practical but it made me realise there is potential for self hosting a web ide.
I get the feeling there is a space for an open web ide to take off. Many of the current offerings are tied to hosted services and don't look overly customisable.
It's not necessarily in a browser. It just seems to be using WebKit as an engine. This means that rather than having to embed e.g. vimscript, elisp, or Python into your editor to make it extensible, you get JavaScript for free. And graphics.
I for one use my own web-based version control system and project management. If there was a good web-based texteditor that is 100% vim compatible, I could stop switching between a browser and a shell.
What sort of stuff do you work on? Do you use a web based editor to modify stuff locally or is it for web based stuff hosted the other side of the world?
I always SSH'd into boxes and edited stuff there if necessary, or had a local copy to work on using "normal" editors and synced it. But now I'm writing C++ so I am blessed with good IDEs so perhaps that is why I am missing the excitement over a text editor?
To be fair, Github wouldn't need to leak anything to get on the top of HN. Just about any thing they post on their blog gets on the front page for at least a few hours.
I saw this. I have a lot of respect for Githubbers and Github but is Node really the language for a text editor? My text editor that's built natively to my OS often struggles, let alone if it's Node. Seems like they're shoehorning the wrong technology.
That commit summary is "Be up front about collecting usage information." If a company can make a better product because they collect usage information, and if they are up front about it and allow you to disable the data collection, then I'm all for it.
Any ideas if all the code behind the editor will be released as open source?
Edit: To be clear, I am not talking about all the supplementary repositories that are already open source, but rather I am wondering if the core application will be OS.
Some interesting new info popping up in the repo: https://github.com/atom/welcome/blob/master/lib/welcome.md - they reference it as being "free during the beta period" - that coupled with a tweet from mojombo yesterday[1] makes it sound like a whole new line of business for them - sounds big!
The way I code (and I'm surprised I seem to be the first person to state this here), is that I can run my class file in Sublime and it automatically runs its unit test within like a second. Instantly, I can know whether I broke anything or whether I satisfied a new assertion successfully without breaking anything else.
Unless this editor can do something similar, this is pretty much useless for any non-html non-css code developer who has already learned that unit test suites are the way, the truth and the life.
I sure hope this will have a rich plugin API and support non-web non-scripting languages as first class citizens. That would make it stand out from most recent editors.
I was excited until I saw it was WebKit based. My confidence level that it won't be slow and buggy is next to zero. I would, of course, love to be wrong.
Domain : atom.io
Status : Client Updt+Delt Lock
Owner : GitHub Hostmaster
Owner : GitHub, Inc.
Owner : 88 Colin P Kelly Jr St
Owner : San Francisco
Owner : CA
Owner : US
If you go to https://atom.io/docs you can authorize the app with your github account. You still get the 'soon' page afterwards, but at least you're now something like an early atom.io beta user ;)
This looks great! I'd be more than happy with an open source, modern editor to replace the current myriad of specialized-language editors (QtCreator, Brackets, ...), Sublime Text and Komodo Edit I'm using.
this is very cool. I think many people are underestimating the potential of something like this. There are 1000x as many people who can hack something cool for this than would do so in elisp.
* I'm a happy emacs user but have to admit this is very promising.
Maybe. For node.js devs. And HTML/Markdown/non-programming coders. Not sure about the others.
A good programming editor must treat code constructs as first-class citizens and (at least partially) operate on AST level, not go with typical "hey, we have a bunch of text that we colorize and bracket-match/fold/dissect with some mostly-working regexp mess¹" approach. The latter is just a notepad, not a decent development environment.
As I suspect this editor isn't much different from notepad/textmate/sublime in this regards and it doesn't really understand a thing about the code I'm working on (just pretends it does), it seems quite useless to me.
Based on BBEdit, which does have a version in the App Store, the plugins and scripting would be just fine -- but the CLI integration wouldn't be. (Although you could probably download it separately.)
I don't really see what the advantage of putting ST in the App Store would be, though, for either its developer or any of the users. I like the App Store well enough for certain things, but for developer tools and many utilities the sandboxing tends to be an annoyance at best.
(Also, I don't like that the App Store makes upgrade pricing completely impossible, but that's a whole different rant.)
I have the same problem with LightTable... ClojureScript is Lisp and all, but why not Javascript? Huge user base, must be faster since its CS target, and pretty good as a extension language (or just use Lua :))
Because it's a modern and usable version of one of the most ubiquitous language of the modern web era (and happens to actually produces that language as an output, making it seamless to integrate)?
Coffee-script is just synthetic sugar with some build in constructors for syntax elitist like rubyist or pythonistas, it not any different than using plain js. It does not save you for the quirks of js or give you any "improvement" beyond the syntax. Is a nice language, but don't put i like is something more of what it is.
Aside from that approach, there are a few faithful Vim recreations that I've discovered out of the dozens that I've tried.
https://github.com/vicoapp/vico (Excellent project) http://www.viemu.com/ (Solid experience in Visual Studio) https://github.com/guillermooo/Vintageous (fairly close and getting better every day)
But I don't mean to sound like such a pessimist. The progress so far looks excellent and I can't wait to try it out. Keep it up!
Edit: I also notice that the logo looks like an iOS7 version of React's logo: http://facebook.github.io/react/