GitHub's new text editor leaked on Twitter(github.com) |
GitHub's new text editor leaked on Twitter(github.com) |
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.
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'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?
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 : UShttps://github.com/atom/welcome/commit/6346bb8c2e7534ae0de5e...
I just hope it's not tightly coupled to the backend so I can replace it with a custom one.
:)
* I'm a happy emacs user but have to admit this is very promising.
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
People like myself who don't use Vim can still navigate code at speed.
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.)
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/
Doesn't that already exist, by hitting 'r'?
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.
• 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.
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.
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
Edit anywhere just with a browser is a win IMHO. Also easy pairing.
The closest alternative currently is CoVim. :x
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.
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.
- 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)
- ...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.
Awesomeness.
"Collaboration is now working (and accepts 2FA logins)."
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."
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.
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.
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?
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
> 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
and i'm fairly sure that paul graham would say that himself.
-bowerbird
https://github.com/atom/welcome/pull/7
Thanks, but no thanks. I don't need my editor sending usage information anywhere.
* 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...
* 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.
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...
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.
[1]: https://github.com/SublimeText/AAAPackageDev/blob/master/Syn...
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.
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.
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.
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.
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:
So I think we sit tight for now, though it looks like a release is imminent.
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
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.
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.
> 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
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.
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.
But to your main point, I would assume this has really really really good github integration...
For one thing though, we can probably expect incredible GitHub integration.
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...
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.
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.
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.
I edit code in vim in screen in ssh.
Used many IDEs in the past, but settled on pure vim.
Thanks!
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.
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.
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...
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.
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.
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!
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.
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.
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.)
(vi, for the record)
[1] http://brackets.io/index.html [2] http://codemirror.net/
Screenshot: http://share.qpleple.com/U8eN
We use to for Go and Docker. Currently, it's very nice. Even has auto-complete - though it has a long way to go.
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.
