GitHub's new text editor leaked on Twitter | Hacker News Reader

GitHub's new text editor leaked on Twitter

github.com

706 pointsalmightygod249 comments

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.

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/

Why not just use Vim?

If it's not vimmy enough, I bet people will.

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 also apparently a pain to integrate into anything else...

http://www.freehackers.org/VimIntegration

...and plugins can't update things in the background...

https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...

etc. I haven't looked at the code myself, but it sounds like a rewrite or major refactor would be very useful.

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:

https://github.com/neovim/neovim

Yeah but this is happening https://github.com/neovim/neovim. And the potential for all you asked for is there, see the long term plan https://www.bountysource.com/fundraisers/539-neovim-first-it....

Curious as to your opinion on Evil from Emacs - I've been learning Evil without knowing Vim first, so I don't know what I might be missing.

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.

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`.

My full Evil config is here: https://github.com/roryokane/emacs.d/blob/master/init.el#L12.... But I don’t see anything in it that would change the behavior of Backspace.

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.

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.

> For instance, I love to bind "s" to "go into insert mode, insert one character, exit insert mode".

Doesn't that already exist, by hitting 'r'?

That replaces the character under the cursor, it doesn't insert a new one.

Ah, thanks for the clarification.

I may be an outlier, but I'm perfectly fine with 90%.

Maybe just use vim?

There's a bunch of lovely gems scattered through the Atom repos. Some of my favorites from a first quick glance:

Biscotto — A CoffeeScript API documentation generator based on TomDoc notation:

http://atom.github.io/biscotto/

React-Coffee — A little glue that makes Facebook's React easy to use from CoffeeScript without having to resort to JSX:

https://github.com/atom/react-coffee

SpacePen: A minimalist view library for jQuery, allowing custom methods, super calls, HTML-building, subviews, and easy event binding:

http://atom.github.io/space-pen/

... and the best bit about this bonanza is that everything is really quite readable. Keep up the good work, Kevin.

I'm confused, why would they be working on React and SpacePen? Don't they do (roughly) the same job?

The editor will be collaborative. It's github.

I have a feeling that started out looking at React but opted to go with SpacePen for some reason.

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…

holy cow this thing has like 70 repositories!

And I found a screenshot... looks very much like sublime text: https://f.cloud.github.com/assets/1424/1228569/cce6eb26-27a6...

edit: based on this[1], it looks like this is a GitHub-aware/integrated text editor that targets both desktop (Mac, at least) and web

[1] https://gist.github.com/elcuervo/eb68883f233baf5a46c8

Looks good. Any idea how we can try it?

well, it looks like you need to use GitHub oauth to sign into it, and doing so currently spits you out here: https://atom.io/nope

So I think we sit tight for now, though it looks like a release is imminent.

now it says "SOON"

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.

Some more screenshots

* https://f.cloud.github.com/assets/671378/2265086/c6897dba-9e...

* https://f.cloud.github.com/assets/671378/2265022/bb148a20-9e...

* https://f.cloud.github.com/assets/2988/1796891/85e69ff2-6a93... (animated gif)

* https://f.cloud.github.com/assets/671378/2241795/ba4827d8-9c...

* https://f.cloud.github.com/assets/671378/2241819/f8418cb8-9c...

* https://f.cloud.github.com/assets/671378/2241519/04791a24-9c...

Seems like to be a Sublime Text clone in webkit?

Maybe an announcement that git bought sublime and this is the web launch of it. I would be so excited if that happened.

You cannot be serious.

The ST builds mysteriously stopped recently (ST3 beta and dev), which is a bit ominous.

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. :)

Exact reason why I think this is great news, it will likely be a more actively developed version of what ST is now... plus some extras

ST development have presumably been stopped numerous times so nothing new about that. Atom have been in the works for at least six months.

I take this as a hint of the author going underground for the next 6+ months, then reappearing and announcing ST4. </snark>

looks like light table

Seems like it has collaborative edit feature as well. Specially the last screenshot.

My first guess was that those are diff markers as you edit.

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.

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.

Light table is only fast is you are a slow writer, the vim mode in it is painfully slow. Webkit base editors like LT and Brackest are unusable to me.

I'm a pretty fast writer and I never had any problem with LightTable's vim mode. Maybe it's just me though, I don't know.

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.

This is already possible using gitgutter in both Vim and ST, and I've never noticed an impact on performance.

Indeed, I'm using it in ST and I haven't noticed an impact on performance.

Screenshot: http://share.qpleple.com/U8eN

Same I use it every day ... perfect plugin :)

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.

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.

[1] http://brackets.io/index.html [2] http://codemirror.net/

Codebox works awesomely well, and you can host it locally. Still has bugs, but they do releases often.

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).

Exactly. It's still very new, but it's really worth a shot if you need the cloud-ide solution.

We use to for Go and Docker. Currently, it's very nice. Even has auto-complete - though it has a long way to go.

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.

Would be really interested to chat to you about Codebox + Docker, email is ben at talkingquickly co uk or talkingquickly on twitter

Sent you an email!

I like my (GitGutter's) concept of displaying removed lines better. This screenshot makes me think line 11 was removed. But I am looking right at it!

Yep, GitGutter is great. Thanks for making 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.

Some more...

* https://atom.io/assets/screenshot-main@2x-e0b7c5a0be2ef13348...

* https://atom.io/assets/screenshot-native-web@2x-2842562f4757...

The second seems to confirm this being web based.

It confirms it as being Webkit based, but not necessarily that it is running on the web.

Found a few more. https://f.cloud.github.com/assets/69169/1625945/b216d7b8-56d... https://f.cloud.github.com/assets/69169/1625938/a859fa70-56d... https://f.cloud.github.com/assets/671378/2241254/23bc3d0c-9c...

Multiple cursor support demo from IRC http://cl.ly/image/3M3G3s251o15

This looks pretty cool, there seems to be Vim shortcuts [1] and even theming. Judging from your screenshot, Solarized Dark is the default theme?

But I'd have to wait until its release (or beta, should I be so lucky!) to consider moving from standard vim editor and Solarized in my Xresources.

[1] https://github.com/atom/vim-mode

hmm.. so it even has an Atom package manager!

I always wonder why I learned emacs over vim. There is never support for it.

Because when you learn elisp, it runs circles around vim.

Yay, the original Holy War!

(vi, for the record)

I'm pretty sure that vi hasn't been distributed for years. All the vi's in modern distros are just pointers to vim.

vi is still included in the arch linux base system

That's probably not true, in that among the myriad distros there's probably one in which vi is nvi.

true, but that's why we have evil mode[1], so we can have our elisp cake and eat our delicous sugary vim bindings too.

[1] https://gitorious.org/evil/pages/Home

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.

I could see that being annoying. VsVim and Viemu both support a vimrc.

Unless you use a Mac!

You could always use emacs evil-pluging.

do you mean https://github.com/tarao/evil-plugins?

I learned Emacs because there was nothing that supported Common Lisp editing the way Emacs did.

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.

Your unit tests running parallelised in the cloud is what I'm hoping they'll get to at some point.

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.

> 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.

You're talking about Emacs, right?

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.

[1] https://news.ycombinator.com/item?id=7240122

It's not really built on React, on a second look.

It looks like they tried it or may try in the future:

https://github.com/atom/react-coffee

But this is what they use for views:

http://atom.github.io/space-pen/

It's closer to Light Table than Sublime Text: http://www.chris-granger.com/images/060/full.png

Only in theme. The layout looks very similar to ST, particularly the menu.

> Only in theme.

Meanwhile not even the theme matches ST's?

> The layout looks very similar to ST

The layout also looks very similar to LT.

> particularly the menu.

The pretty standard tree view? Yes, it looks like the very similar tree views used for the exact same purpose in LT as well. How surprising.

> The pretty standard tree view?

Pretty sure he's referring to the popup menu for shortcuts that ST has as seen here: https://f.cloud.github.com/assets/2988/1796891/85e69ff2-6a93...

> 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].

[0]: https://github.com/atom/fuzzaldrin/blob/master/src/filter.co...

[1]: https://github.com/atom/language-toml/blob/master/grammars/t...

[2]: https://github.com/ajaxorg/ace/blob/master/lib/ace/mode/asci...

[3]: https://github.com/textmate/toml.tmbundle/blob/master/Syntax...

so the grammars are still a bunch of regexes? that'd be kind of a letdown

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.

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.

I hope they won't use this awkward "double-escaped backward-slashes in reglular expressions" environment. YAML[1] is much better for this.

[1]: https://github.com/SublimeText/AAAPackageDev/blob/master/Syn...

> I hope they won't use this awkward "double-escaped backward-slashes in reglular expressions"

Yes, they will[0]. YAML is definitely better, but I believe they have a strong opinion against YAML[1].

[0]: https://github.com/atom/language-toml/blob/master/grammars/t...

[1]: https://github.com/mojombo/toml

Haha. https://twitter.com/shit_hn_says/status/278710645644484609

This sounds more like the future than having to get an expensive computer and setup a whole environment on it.

Haha - that's great. Here's the original HN discussion being referenced.

All of the competition can only be good for us developers. This, ST3, Light Table, Brackets, etc. Bring on the text editor wars!

Don't forget IDE family like http://c9.io/

Edit anywhere just with a browser is a win IMHO. Also easy pairing.

Love C9 as well, been a big fan of that one since its early days, thanks for adding that!

c9 is awesome! One thing keeping me though is realtime collaboration in the open source edition. (Gotta self host, flaky internet).

The closest alternative currently is CoVim. :x

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.

I checked it out (as recently as yesterday, right after my comment), but it is too buggy and featureless for me.

Why not edit anywhere with an ssh client (ie. use vim)? Less overhead, more compatiblity with existing tools...

Meanwhile, vim and emacs are sitting in the corner and quietly snickering.

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.

The videos on your site don't load for me. I've turned off ad blocks...

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...

> 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.

http://blog.atom.io/ seems to be WIP, the meta tags are quite revealing :

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.

Pretty crazy! Here are a few interesting plugins in there already:

  - vim-mode
  - fuzzy-finder
  - emmet (aka Zen Coding)
  - solarized-dark-syntax (heh)
  - snippets (check)
  - language-* (check; so many; awesome)
  - timecop (tracking where time is spent in the editor)
  - editor-stats (graph your mouse / keyboard activitiy)
  - ...

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.

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.

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.

Flattered to see it using marked for the markdown engine. Maybe the world is finally ridding itself of showdown.

What's wrong with showdown? Legitimate question - I just haven't heard of any complaints about it before.

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.

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.⁴)

[¹] https://github.com/evilstreak/markdown-js [²] https://github.com/shamansir/mdown-parse-pegjs [³] https://github.com/sheremetyev/texts.js [⁴] https://github.com/rhythmus/markdown-resources

Thanks.

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.

chjj said:

> Flattered to see it using marked for the markdown engine.

i am amused as well.

because i just did this the other day:

> http://gitdown.wordpress.com

"gitdown" -- so we can all get down...

i also wrote a piece called "markdown considered harmful".

> https://medium.com/the-future-of-publishing/495ccfe24a52

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.

-bowerbird

FYI https://atom.io is leaking assets. Here is an album of the images found in the css http://imgur.com/a/KG4MX#0 the css http://pastebin.com/FgN3g448 the js http://pastebin.com/p1nBmGki

The most vital one, showing it wants to be hacked at (in a good way): http://i.imgur.com/XmLcOhB.gif

Awesomeness.

That's just for a welcome dialog.

Well, crap, they've certainly got enough pictures of rockets. Sign me up!

atom! to the moon!

Looks good and all... but I'm interested in the story on how it leaked on Twitter. The link just goes to the Github repo now.

This kicked it off: https://twitter.com/mattetti/status/438494095506280448

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.

https://f.cloud.github.com/assets/1424/1228569/cce6eb26-27a6...

"Collaboration is now working (and accepts 2FA logins)."

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.

TextMate is still alive: https://github.com/textmate/textmate

But to your main point, I would assume this has really really really good github integration...

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".

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.

I digress, I'm just excited by this.

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....

I realize that vimscript or elisp may not be your cup of tea, but you can already have exactly this "hot reload" experience with both vim and emacs.

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.

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.

"Atom is free during the beta period." https://github.com/atom/welcome/commit/86790ef7cca263ca0943f...

Seems like they're going the ST route. I'm kinda disappointed Atom won't be open sourced.

Maybe. https://github.com/atom/welcome/blob/master/LICENSE.md https://github.com/atom/welcome/blob/master/CONTRIBUTING.md

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.

Cloud9's open source edition has a few features missing, most notably realtime collaboration.

They're on Twitter: https://twitter.com/AtomEditor found the link in the Source Code of: http://blog.atom.io/

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."

Never thought I'd be excited for a text editor, but damn I can't wait for this to come out.

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.

It seems that Holman has already used it 5 months ago. https://github.com/holman/feedback/issues/432

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....?

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?

I work on web based stuff on the other side of the world.

I edit code in vim in screen in ssh.

Used many IDEs in the past, but settled on pure vim.

Ah I see the draw of an editor in a page then. Now I understand the excitement.

Thanks!

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.

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.

whois atom.io =>

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

Dig the feed URL: https://github.com/atom.atom

Website now says "SOON". Response from #atom irc channel:

> Would the editor itself be open-source?

> yes

> a non-opensource editor from GitHub would be ludicrous

> seems like the source code will be up today

The person who answered you isn't associated with GitHub and has been trolling the channel (and apparently you).

top of HN = leak well done = planned? maybe.

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.

notions of fairness aside, github doesn't need hackernews. in the slightest. for attention, or for anything else...

and i'm fairly sure that paul graham would say that himself.

-bowerbird

Lets reinvent everything in javascript no matter how badly...

There is freedom of choice. You don't have to use it.

Still, he is entitled to his opinion. You don't have to downvote it. :>

Sure

coffeescript and cson, specifically.

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.

Apparently it collects usage information?

https://github.com/atom/welcome/pull/7

Thanks, but no thanks. I don't need my editor sending usage information anywhere.

"If you do not want this information reported, disable this package from the Metrics section of the Settings view"

https://github.com/atom/metrics

I saw that as well, but opt-out is a crappy default. It should be opt-in.

Why do you care?

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.

I'm very curious too. This may make or break it for me.

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!

[1] https://twitter.com/mojombo/status/438200146791129088

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.

Looking good and this only helps confirm that web IDE's are going to be the big thing in the next couple of years.

I've been predicting/preaching about this for 2+ years now and been building my own browser code editor in that time (http://icecoder.net).

So, CodeAnywhere gets $600k in funding, Adobe is releasing Brackets to the browser soon, GitHub is launching Atom as a web based offering.

Need much more reason to leave the desktop behind?

Do any of these support an offline mode?

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.

IRC channel here: http://webchat.freenode.net/?channels=##atom

the vim-mode better be really good to make me switch from native vim.

The future work section of the readme (https://github.com/atom/vim-mode#future-work-in-rough-order) lists some really basic stuff, so it's definitely not there yet.

http://whois.domaintools.com/atom.io

  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

Glad to see there's an Atom plugin[0] named after the Jean-Claude Van Damme movie Timecop[1]

[0] https://github.com/atom/timecop

[1] http://en.wikipedia.org/wiki/Timecop

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 ;)

Will this support Linux? I would love to try this on my Linux System. (Ubuntu, to be specific)

looks like it is built on node-webkit so probably yes.

where did you find that out? just curious

package.json everywhere.

I like that they are already prepared(/preparing) for Node 0.11, (https://github.com/atom/node-vm-compatibility-layer)

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.

Atom IRC channel

https://github.com/atom/welcome/commit/6346bb8c2e7534ae0de5e...

https://github.com/atom/welcome/blob/master/lib/welcome.md

Looks 1000x times better than a project I just started based on Ace.js. Should save me a lot of trouble!

I just hope it's not tightly coupled to the backend so I can replace it with a custom one.

Was worth a try...

https://twitter.com/s10wen/status/438637833981820929

Looks like this is going to be released today http://minus.com/i/8HXqEh53LTsB

How is this a leak when THEY HAVE A WEBSITE with a signup form? http://atom.io

Very likely that Github bought SublimeText.

Why do you say that?

Atom: http://i.imgur.com/0Qfwkp4.png

SublimeText: http://i.imgur.com/frzYwwc.png

Case in point.

They look similar. I'd like to be proven wrong and GitHub make Sublime a more maintained and transparent project, but it's doubtful.

I think if this kicks out good and will have plenty of plugins sublime will be dead in a matter of months.

The UI is undoubtedly similar, but Atom appears to be written in Coffeescript. Isn't Sublime written in C and Python?

Couldn't this effectively be "Sublime Text 4," written from scratch using ST3's proven approaches? I honestly have no clue, I just want to believe.

Why? Because they made a clone?

And then promptly rewrote the entire thing in Node.js? Huh?

As the actual editor isn't publicly available in any form, this isn't exactly a "leak".

Any word on how to get in on the beta?

It sounds like they're preparing to open this to the public. I don't know, though. We'll just have to wait and see.

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.

And I will continue to use an Arch Linux VM, i3, vim, and dwb...

It looks like gitblime bought subhub, just kidding. :P

the next big thing for devs. I love sublime and will, but can't figure why is it taking them so long, to launch it on mac appstore.

Apple's 30% cut

Yeah, there's really no incentive for them do it aside from accepting non-Paypal customers.

paypal accepts transactions without accounts just cards...

Not if it's the same card used on a limited PayPal account :)

Not to mention the amount of features they'd have to remove in order to comply with Apple's standards.

Would its plugin / scripting library even be allowed? I don't know the specifics of the OSX app store rules.

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.)

Curious, what is the added value for you if it is on the App Store?

Because?

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.

___

¹) Like this: https://github.com/atom/symbols-view/blob/master/lib/.ctags

Is this a replacement for gist?

No. Gist is a service.

Guess, github bought sublime.

No.

They open beta invites today

Looks amazing, but why CoffeeScript?

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.

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 :))

I'll re-phrase an earlier comment: JS is the x86 of the web, so why argue about which macro syntax is superior?

GitHub's guide for javaScript is to write every new JavaScript in CoffeeScript. https://github.com/styleguide/javascript It has been like that for years.

If it doesn't come with a vim-mode or that vim-mode is slow and painful to customize, then this will be useless.

That's not true.

People like myself who don't use Vim can still navigate code at speed.

I think what jbeja meant is "this will be useless for me"

Reply on news.ycombinator.com