"free during beta" doesn't always imply "paid on launch" and I'd be surprised if the basic editor was paid. Github certainly doesn't need the cash and usage is oxygen.
Agree. It's a tough decision for them -- I'm sure the "Hot New Text Editor" market has a decent chunk of money associated with it. But it's pretty hard to commit to a text editor that you can't open up and recompile.
EDIT: Plus, if an editor is going to join the ranks of vim and emacs in history (something which neither Sublime nor TextMate are on track to do) it has to be open source. Anything else and it's just another product.
I agree on the open source nature. However if this editor treats github as a first class citizen (while being free/open) then it does have value to github. This is especially the case for new github features introduced in the future.
There are very few people who would opt in to a editor for everything only to use it with Github. Most of the world's developers don't even have a Github account.
Tools work in a strange way. I recently saw a whole team of embedded developers use TextPad. They haven't heard of anything called 'vim' or 'emacs'. From their perspective its either a vendor supplied IDE or TextPad. One of them was even startled to see this shiny new thing called 'Sublime Text' when I was using it. He went out with enthusiasm, but was hardly able to convince any one to use it.
A code editor with first class prominent Github support is more likely to encourage creating Github accounts - it would just work. Compare to regular code editors which require jumping through various hoops (typically having to find relevant plugins, install them on all machines/users, and then figure out how to use them as they are extensions not core).
A pitch of "if you use this editor then all the team's work is automatically synchronized and available" is a very powerful sell.
Vim is available on all (relevant) operating systems.
Vim doesn't require an invite.
Not for me. I do like to give new editors a try (fell deeply in love with LightTable just a short while ago), but OS X as main platform and yet another closed editor?
There are open source text editors of all levels of "easy to grasp". I've contributed to one myself. With Atom I simply don't have the option, and that's unacceptable as a professional in this craft.
I agree, I'm just saying that if some capable people decide to stop working on Emacs, it would die. So sometimes I prefer a paid product because there is incentive to continue working on it. (Ok, not that the karma/love one gets for working on Emacs isn't good enough).
I'm really hoping they make it completely open source with service-optional business model, they core needs to be open or it will have the same problems as every other closed source editor.
Usually if you don't see "free" or "open source" mentioned on the main page it means it's not going to be either of these two (or at least that it hasn't been decided yet).
The tabs are the thing that reminds me most of ST but they are practically just Chrome's tabs -- everything else isn't particularly distinctive and seems standard for a text editor.
But the very first thought is "wow, it's exactly the same look as Sublime Text", not JetBrains product, not Eclipse, not even Visual Studio, so they definitely were completely inspired by Sublime in particular.
True; but if you were making a text editor today, with the whole flat UI trend and minimalism being so prevalent, the sublime UI is actually very intuitive. It's just that sublime got to it first, in my opinion.
As the designer who worked on the main interface for Sublime Text 2, it does irk me that it looks so similar. They had carte blanche to create a wonderful new interface and they mostly just copied Sublime Text. The go-to anything menu looks especially similar. https://t.co/5YxVbZcVcK
As was speculated in the other thread the beta looks like it will be closed, there's a "request and invite" form on the page.
Others noted that the source mentioned "free during beta", I certainly hope that's not the case and it's truly FOSS. Sublime Text development has slowed significantly recently and the community can't continue to drive it since it's closed.
Funnily enough, Sublime Text was born out of Textmate development slowing, and I can't seem to shake that vibe here too.
If you want an open-source text editor based on Node.js, Light Table might interest you.
(Light Table itself is written in ClojureScript, which is a bit idiosyncratic, but it's hardly worse than Elisp, and anyway you can write plugins in normal JavaScript.)
I think he means that we need editors that are powerful AND easy to use.
Seems like vim isn't really for someone like me (I haven't studied PhD level computer science and I don't write compilers and/or lisp interpreters in my spare time for fun).
You don't need to do those things to use vim. It just has a kind of steep learning curve -- one that has to do with just getting used to its keybindings (ie, nothing to do with PhD level cs or writing compilers).
Not to get on vim tangent but it's very easy to learn vim slowly. If you use a gui like MacVim you can still use cmd+s to save, etc. and use it like a normal editor. The only thing you are really required to know is the difference between normal and insert modes.
Yeah, I understand what you're saying. It's just hard for me to justify (to myself) learning vim (or emacs, or vi, or whatever) when I can just load up Sublime Text and start working on something.
Put another way: working with Sublime Text and Adobe Brackets is a good experience for me... There's nothing that screams out at me "Man, this sucks, I need to go learn vim."
Fair enough, can't blame you for that. If you ever start wanting to administer your own servers, being handy with vim is nice as you can quickly make changes on an ssh server.
Vim is hardly a requirement to manage a server, and the amount of changes required live on a server should be approaching zero - apps should never be written on the server and even config files etc should be handled by some form of config management - chef, puppet, debian config packages, etc
Vim is actualy pretty easy to use, the learning process is not hard at all you could just go through the vim tutorial that comes with and you will in good shape in no time.
I'm sure it's not terrible to use, but I'm not sure it's worth it for a caveman like me to put time into learning it. Sublime Text and Brackets already work very efficiently and allow me to focus on getting things done.
Of course, PHP people probably said the same thing when Rails came out. The difference is that current GUI editors are already very advanced. I'm skeptical that I would get any efficiency boost from vim (at least anytime soon).
I taught Linux Admin courses before I graduated high school, and the first order was learning vim. If you have a mac, 'vimtutor' is available to you.
vim has nothing to do with PhD-level CS or writing compilers and/or lisp interpreters. The Emacs community might fit that stereotype a little more but really not much more.
Vi (vim being 'vi improved') is great because it works on basically any terminal. It works with my iPad's keyboard and with a teletype terminal from the 70s or 80s, as well as a normal PC keyboard. Emacs has similar brags.
The terminal's not going anywhere and if you like keyboard shortcuts, knowing five or ten that will work on any keyboard in existence for an editor that is on most unix systems you'll find has some value.
I was being a smartass, which was uncalled for. Sorry, Angersock!
Also, I do have a mac, so maybe I'll check out vimtutor.
My point is that I'm very new to programming, and it's so much easier for me to load up Sublime Text and start getting work done. At least for now, learning vim would be something that get's in the way of learning/making. It also doesn't seem like the benefits would outweigh the cost.
I started using vim when I had first started to learn to program. I'd say give it a shot if for no other reason than it's an interesting paradigm shift, and can be really effective.
I'd say give Vintage mode on sublime a shot. It does the basic keybindings/motions of vim and will give you an idea of whether or not you might be interested in it. It's also nice because in insert mode it's basically just normal sublime, so you can just switch back to that if you get frustrated.
Are you on linux, osx, windows, or something else?
If you use vim/vintage mode, remap capslock to be escape.
This took me forever to figure out, for whatever reason, but if you're on windows, the easiest thing to do is get autohotkey [1] and write a script with one line:
Capslock::Escape
You can compile that to a portable binary and use it anywhere as well. It's really straight forward.
I also added two keybindings to make Alt+movement to add cursors above and below:
{ "keys": ["alt+k"], "command": "select_lines", "args": {"forward": false} },
{ "keys": ["alt+j"], "command": "select_lines", "args": {"forward": true} },
It doesn't always interact naturally with vintage/vim mode, though, but that was just a personal preference.
Wow - I didn't even think node.js was that old. It will be interesting to see its genesis. The first git commit for node appears to have been on Feb 16, 2009:
commit 9d7895c567e8f38abfff35da1b6d6d6a0a06f9aa
Author: Ryan <ry@tinyclouds.org>
Date: Mon Feb 16 01:02:00 2009 +0100
add dependencies
To be fair, would most people know what super-shift-P means?
That said, it would be fairly simple to have a variable for super that resolves to ctrl/cmd on other platforms, the same way that most download pages nowadays infer your platform and show you the binary you most likely want.
The most common cause of people showing websites inside a Macbook is that the graphic designer is using a Mac and Apple provides some pretty nice high resolution tiffs of all its products.
It's built on node-webkit and chromium, which technically works on Windows, OSX and Linux. Do you seriously think they would make an OSX only editor when there's already so many that work on all platforms?
If it is inside node-webkit, I'll be curious to see how they got native windows menus support. There are some pretty serious bugs in NW's handling of windows native menus.
Cheaper hardware, Steam (and other games in general), testing on the platform used by a majority of our users, and more customization available than OS X, for starters.
It's most likely not possible until there's a "hosted atom" you connect to with your browser. ChromeOS is /just/ a web browser and won't run node, which Atom uses to do its processing.
It will depend on which node features/packages are essential, but it could probably be hacked together (possibly entirely using Atom's modular design, e.g. replace the standard file IO parts with browser-friendly ones like LocalStorage and the HTML5 File API).
@Downvoters: Please do your homework[0] before downvoting. If you genuinely think my comment deserved downvotes, at least afford me the courtesy of an explanation.
It's really sad that learning a new language is considered "a big obstacle." An average programmer should be able to pick up nearly any new computing language quite easily.
The language itself is actually very simple and writing plugins for lighttable is the opposite of complex, there are amazing tutorials floating around the web. The whole process is simply just manipulating sets of data, it's all about adding and removing triggers.
This said, you can also write lighttable plugins in javascript.
Can I use it online? That would be the killer feature for me, being able to code on anyone's computer in a second. Currently it's basically the only thing stopping me from being able to pick up anyone's computer and use it as I use my own.
Guessing no, because of the Node.js plugin architecture ("need to call into C or C++?", "full access to the filesystem"). Really only the UI seems to be done in WebKit.
From a quick glance it looks like its architected the same as Light Table (Local node server that accesses the file system and a decoupled UI that connects over http and uses WebKit).
If it works like that it could run in the browser. Not so easily from anywhere though
If vim works great for you, then rock on! We can't have too many editors, though. Bad ones will fail to gain traction, and it's always good to get new ideas and modern techniques out there.
I've sworn by SublimeText until now. And Atom is getting released during a time when I'm increasingly learning to love console-only computing. I envision a day when I can travel the world with a cheap laptop/chromebook and do all my coding remotely via SSH.. and Vim is very much at the core of that dream.
Try using the Vim plugin (Vintage or the newer one, Vintageous) with Sublime. That way, you can gradually get used to modal editing.
I worked like that for 8-10 months then made the switch to Vim. I've gotten so used to modal editing (not to mention window management etc.) by then, that I didn't even skip a beat.
I was like that while using ST2. But then better plugins started appearing for ST3 (the aforementioned Vintageous being one of them) so I switched to ST3.
But it crashed constantly; also, by that time the Vim emulation was really hurting me. The dot command was anemic, tabs were interfering with splits etc.
I do that currently, but using the local graphical editor. I just mount the ssh path to my local FS using Expandrive. It's not free but I can recommend it.
I've never though about that! But it sounds great! A question though... I don't know how much though you actually have put into this, but I'm curious. What do you consider a cheap computer?
I do all my coding (though it mainly web, which arguably might need less resources than other languages) in a medium tier pc. It's a lenovo B590 with an i3, 8GB RAM. It's not exceedingly fast but with two windows of chrome, 20 tabs each, 5 or 6 instances of PHPStorm open, and all the usual programs (email clients, dropbox, chats, etc) it still feels quite snappy.
The cost here in Austria was around 650€ or so in total, maybe less (I'm not quite sure now because I upgraded it little by little).
My question is if your plans are set around a dirt cheap machine that you "wouldn't care at all" if it gets stolen, lost or broken... Or something more in the lower middle class where you'd have to be careful not to lose one per month, but you could still run most of the stuff you'd actually need for local development.
This question arises mainly for my concern is greater about not having a working reasonable internet connectivity hence making it difficult to work over ssh, rather than the laptop getting stolen or broken.
> two windows of chrome, 20 tabs each, 5 or 6 instances of PHPStorm open
Jesus Christ, that sounds excessive.
Vim can be run well off of a $35 Raspberry Pie if that means anything to you. That machine has 512 MB of RAM. Basically every laptop will be able to handle it just fine.
Theoretically yes, practically it will be slow, but it's no the CPU/RAM it's the SD card (poor I/O speed) that slows down VIM on embedded devices. You have to disable swapping, you could load your current working dir to RAM and them write a script to save the data elsewhere but that's dangerous for production.
So the best device to run vim IMHO it's still a top-notch SSD-based laptop. A chromebook (intel-based to avoid other sort of issues) would be a better bet.
The big difference from my perspective is that Atom isn't currently FOSS. Other than that, the maturity of the emacs ecosystem is both one of its greatest features and a bit of a curse.
40 years of legacy decisions can be a huge weight on a project, but reinventing a newer, rounder wheel has pitfalls as well. I'd love to say 'I want a modern version of emacs' (or, in my case, vim), but I'd be terrified that I'd end up with a TextMate2-style second system syndrome.
It looks like the GH guys have worked around this problem quite well, and I'm looking forward to begging, borrowing, and then just begging again if I get a chance to try it out.
The non-FOSS part is the part that bothers me the most. Maybe bothers is too strong a word. It's just hard for me to get into a text editor without knowing that the community could pick it up and run with it, if the originator dropped it.
Not sure if that's an unfounded fear, but I don't want to invest time customizing a platform and writing plugins when it could close shop in a second. I suppose I could say that about a lot of things I do customize, but it's hard when the FOSS text editor world is so rich.
One reason I like using Emacs is that I can run it in a terminal - e.g. over ssh. I am skeptical I'll be able to do that with Atom (without using X forwarding).
On top of that I can be up and running with Emacs on a fresh install of just about any linux distro: install via the distro's package manager, drop in my configs, done.
Wow. Lost karma because I'm enthusiastic about something? Neutral, I'd understand... but downvotes? Really? I've seen even more plain and simple comments get upvotes. You folks are a fickle bunch.
You already can, just load up a crosh window and enter your chroot. Take your pick of vim or emacs or whatever other console editor. Or, if you're enterprising, you can run a window manager on the same X display and use any GUI editor, but the integration is a bit wacky.
The editor looks good. I'm more excited about the fact that this is a good looking desktop app, built using, what are normally considered, web technologies.
I've been wanting, for a long time, to be able to have custom UIs to websites (just like how video games do it). If this is a step in that direction for github, I will be very, very happy.
It could be really great. I wonder if Jon Skinner knew, and said to himself "Welp, I might as well stop with Sublime". However, Sublime is (mostly) blazingly fast. I don't expect this from a node based app, especially in Windows. And: I didn't see it under Features, but Atom definitely needs the command palette from Sublime baked into core. Only if it's core, plugin authors will set their hooks correctly from the beginning. Or even better, there might be a flexible command api that exposes each plugin's commands from the start and can be extended too. -> edit: the readme says it has Command Palette. Great! Also, since the term is identical with Sublime Text, I wonder if there's more to it than inspiration.
Although, most of the Sublime core is in C/C++ as far as I know. And it's using native drawing, not webkit. Will be interesting to see how the performance compares.
sublime is using opengl to render every glype. Its speed will blow anything out of the water. Open 2MB text will be highlighted and colored in an instant. I wonder how could webkit achieve that.
My suspicion is sublime's speed has very little to do with its rendering method and a lot more to do with its I/O philosophy. Because, let's be honest, there is no way OpenGL can make loading a 50mb file into memory significantly faster than plain rendering.
You're missing the point. The point is, for some reason a bunch of people have their expectations of Javascript performance set 10-15 years out of date.
I would pay for a $10 a month subscription/support contract to Sublime if it was Open Sourced... properly where the community can get involved in the development.
This coming along scares me that an already tenuous situation around the future of Sublime Text may implode due to this new editor... and it isnt even open source. I'd rather build my own highly customised GUI+CLI macvim/emacs with both python and JS plugin backends than switch from one closed source editor to another just because its new and uses Node... I dont normally swear on hacker news ... but fuck that shit.
before you jump to writing your own text editor from scratch, consider contributing to textadept. it's about half the text editor that sublimetext is, but it's lua based, already exists, and it is totally open source.
Good catch. I really shouldn't have any more of a problem with a desktop app tracking me than I do a web app but for some reason I do. I guess because I can always use Disconnect in the browser and I can't with Atom. I guess the fact that it is open about it is a positive thing, though.
Some apps ask on install if you agree to share usage data. I can't say how Atom handles it, but it sounds like you're in unless you modify the config.
BTW, I'm less concerned and more just surprised to see Google Analytics used like this. I guess it really is the blurring of the lines between desktop and browser-based apps.
Maybe this GA usage is not unique, but it's new to me.
Why should I care about a Google key-logger with a bundled text editor? Also, if github were a real player, they would do their own user tracking rather than giving Google their data.
Bracket is built on top of Code Mirror. It never feels like a native editor. If Atom is using a Webkit renderer for core editor part, I'm not gonna switch from Sublime anytime soon
Light Table is build on Node-Webkit and it feels pretty good most of the time. (Opening folders is the only spot I've found where it's like, "Wait, something is a little off here.")
I am very excited about this, I love the Github team and this looks like a great tool.
My only question is -- why should I switch to this from Sublime Text? Are there specific use cases it handles better out of the box, or is it more of a modular base that will be expected to grow and outfeature ST2/3's seasoned plugin economy? I am very happy with Sublime Text now, but I would be willing to switch if either it gained a lot of traction, or could do stuff that I couldn't do with Sublime.
I don't see a reason to take that as a given. This uses node, ST uses python. Sublime plugins have a huge amount of power and python is certainly not terrible to work in.
I've been playing with it for a few minutes now, and it's definitely the case that it's easier to tweak. Not because of the underlying language, but because they expose so much of what's available through a GUI.
I'm blown away by how cool this is. I'm just really hoping for good Vim keybindings and I will pay good money for this once it's out of beta.
I was given 3 invites, I gave away 2 but I'll give the third to the first person to email me. (EDIT: gave away the last one)
Doesn't seem like they're keeping too tight of a lid on it, but I guess we'll see. It seems like it can be freely passed around; I think they're just trying to gauge interest since it won't be free after the beta period.
A good VIM keybinding plugin is a must for me as well. The one available for LightTable, for instance, simply wasn't sufficient IMO. I can't specifically remember what it lacked, but it was enough to throw me off.
Vintage mode in ST2/3 isn't perfect, but it's pretty solid.
Atom looks interesting. I really look forward to trying it out.
Don't hear as many folks talking about emacs in evil mode. I tried that out for a bit, and I'm not really sure why I didn't stick with it. I used it a few months. I always liked the modal nature of vim and the operator/motion sequences, but I'm a fan of lisp/emacs and remember enjoying how emacs was put together more, from a modification standpoint (I don't remember any of it now)
Yeah, Vintage mode was okay. I liked the Vintageous plugin a bit better but even that left me wishing for Vim some of the time (more time to adapt might've helped).
Other than that, it seems like an incredibly well-designed editor. Really looking forward to seeing what happens to it now that it's out in the open.
In practice, the ST3 API is extremely limiting and poorly implemented. The docs are both lacking and dated (read incorrect). It is trivial to crash ST3 by making the incorrect sequence of correct API calls. It is also common to resort to polling the editor to make up for other deficiencies. The API also only allows for extremely limited UI choices forcing highly unintuitive interfaces on end users. The ST3 runtime also features such gems as not shipping the ssl module on linux (while ST2 stripped out even more stuff).
I also expect NPM to be much better in practice than the sublime package manager which frequently ships broken code. JS is a better choice than python for async code which will make writing plugins easier.
Furthermore, ST is 3 people who largely ignore all feedback from the community regarding bugs and features. It won't be hard to out compete ST in the long run.
I am a co-founder of floobits- https://floobits.com/about. We build support for real time collaboration into existing editors. I chiefly work on our editor integrations.
In terms of ease of development, the order goes like this:
IntelliJ ~ Emacs > Sublime ~ Ace >> Vim. In terms of community and support, the former ordering is also true.
POLLING:
Here we are trying to get the Window, from the Sublime API. Sometimes it doesn't exist (even when windows are open). There is no reliable API to tell us when new ones are made or when old ones go away. Presumably, post_window_command (http://www.sublimetext.com/docs/3/api_reference.html#sublime...) would fire off with a close command, but this function has never worked.
Here is another example of pure craziness forced on us by ST3. We need to patch Views, but ignore our own patches (locally) so we don't form an echo loop. We also need to move the cursor so it doesn't jump. Sublime deals with these changes so poorly, we are forced to jump through hoops. In contrast- emacs/vim/intellij are basically fine just dumping on the entire buffer.
I don't know if I'd call it extremely limiting… there are some places I'd like to see more accessibility. However, I've built some pretty extensive stuff with it.
I would love to see ssl compiled in - I believe the reason Jon currently doesn't is that it would require building on at least 6 different machines to cover 0.9.8 and 1.0.0 (libssl.so.10 and libssl.so.1.0.0) for x86/x64 plus a customized version of ssl.py.
I've been using ST2 a lot recently and while I really like it, feature wise, I've had horrible issues with documentation. The big issue is that it doesn't seem to meaningfully exist, especially if you're looking to quickly start modifying things and creating new functionality. Maybe I missed the boat on it somewhere, but it's a nightmare to find anything out about it that isn't pretty simple. I've ended up doing a lot of digging through the keybindings, experimenting with random keywords, and reading other peoples code to get things to work. While that in and of itself is a learning experience (and there's something to be said about reading other code), it's hard to rftm when there's not really an m.
I guess it may be that my google-fu is just sucking lately, but the docs situation seems bad after a few weeks of using it. If I'm wrong and anyone has any suggestions, let me know and I'd really like to check them out.
This is dead accurate. I'm a huge fan of Sublime, but their API/documentation is an atrocity. As much as I love my current Sublime setup, if there were an editor with a well documented API for writing custom plugins I would switch in an instant.
Indeed. I tried to implement a fast project switcher plugin at one point; ie., a plugin to quickly switch to another window by autocompleting its project name, like super+P (instead of having to cycle windows or use the window menu, both of which are poor UIs when you have anything more than two windows open). But the API doesn't support focusing windows. You can switch focus to a different buffer in an arbitrary window, but it won't make the window itself active. I reported the limitation in the forums. Never got a response. Didn't surprise me; I have reported a bunch of other problems, hardly any of which received Jon Skinner's attention.
I like sublime, but my primary computer has an ARM processor and there is no sublime port. The sublime developers have stated that they don't have the bandwidth to handle an ARM port, and that's fair. But I find it difficult to justify paying for a license, when I can only use the editor ~25% of the time. An editor that is sublime-like and works everywhere would be awesome. I can't tell if atom has this, but a hosted version would also be cool, allowing users to hop on the service and do some quick work when on unfamiliar machines.
Yup, the Samsung model. Use it for most of my work. I've got an old clunker that is x86, but that thing is showing it's age so only use it when it's absolutely necessary (when there is no ARM port for an application i need, for example). The battery life and weight/size of the chromebook are really awesome. Using crouton to run an OS is pretty painless, although you do run into a few bugs every now and then. Also, the hard drive needs to be supplemented with and SD card. But for the most part, works as good as a MacBook Air for a quarter of the price.
The moment that their new editor provides some piece of Github functionality that isn't exposed to an open API is the moment that we need to bail, en masse.
We've already killed Freshmeat and Sourceforge for turning lame, this shouldn't be hard.
You know, I'm usually very skeptical of web apps, but building a text editor in WebKit actually seems like a really good idea. Everything a browser should be good at — text display, scripting, styling — also applies to text editors. You don't really have to worry about complex UI, animation, or user input. You also get remote access almost for free.
What other text-centric apps can be made better by a browser framework? Maybe the terminal?
HTML's not good at windows, apps, doesn't have any sort of concept of a widget and has the kind of layout rules you'd have a tough time beating if you were sitting there trying to be deliberately malicious to future programmers.
It's not a good idea, but given the abysmal state that desktop apps seem to be in at the moment[1], it's probably the least bad idea.
[1] Been about 5 years since I did a desktop app, but if anything they look to be getting worse. WPF, flop. Flex, flop. GTK+ looks poo. If I had to do a cross platform desktop app, I wouldn't even know where to start.
I agree with you, but I don't think most of those things are really vital for a great text editor. For the most part, it's just a giant window with your text in it, maybe a sidebar or two. Most of the magic happens under the hood. That's why I think this is a good idea.
Dunno about cross-platform app development, but Cocoa on OSX is pretty nice. QT isn't bad either, from what I've tried.
So why is every text editor I have ever seen embedded in a website an abomination?
> text display, scripting, styling
The only thing that really matters is scripting. Every serious editor has solved displaying text and styling since ages and those two points aren't even that important in programming languages. All you want is a syntax aware highlighting. Maybe underlines and a little bold here and there.
Scripting is the really hard part. There are many flavors, languages, APIs to chose from. Just because you now can script things in <hip-language-of-the-day>, the problem isn't solved. My editor uses a lisp dialect and I'm perfectly happy with it, not because of the language choice but the APIs and amount of integration.
One thing that is incredibly important for text editors is speed: something web engines are notoriously bad at.
"Every serious editor has solved displaying text and styling since ages ago..."
Sure, but why reinvent the wheel? In this case, Github is leveraging a technology specifically optimized for text and styling. They don't have to maintain it, and they get a lot of cutting-edge optimizations for free. It also gives them the freedom to do some crazy things that would otherwise be very difficult — see Light Table.
"...and those two points aren't even that important in programming languages."
I disagree. Efficient text display and presentation in a text editor are very important, at least for me. Not that scripting is any less important, but it looks like Github has that front covered as well. (Then again, I've never been a heavy vim or emacs user. I guess I'm what you might call a "filthy casual".)
"One thing that is incredibly important for text editors is speed: something web engines are notoriously bad at."
I was under the impression that web engines are really good at text when there's not a lot of other crazy nonsense going on. Guess we'll see!
"So why is every text editor I have ever seen embedded in a website an abomination?"
My guess is going (partially) native and using Node.js will make the experience a whole lot better.
> So why is every text editor I have ever seen embedded in a website an abomination?
Because most websites use contenteditable for their rich text editors, which is horrible to deal with. It's not standardized, it gives developers very little control, and its output and capabilities vary a lot from browser to browser.
Web rich text editors that don't suck - e.g. Google Docs - bypass the browser's support for rich text editing entirely. This makes them usable, but it also means everything has to be implemented from scratch, so the code is complex. AFAIK there are no general purpose rich text editors built like this that are open source or even licensable.
There are some pretty good non-contenteditable code editors, though. Presumably Atom will be built in this style.
So this it yet another web base text editor like Brackets and LT, one have it's "live-reload" feature the other his "live-code-evaluation", and which is the selling point for this?. Going throught the website it just give me the idea that is a what i mentioned before.
661 comments
[ 3.5 ms ] story [ 444 ms ] thread<DouweM> kevinsawicki: is the actual core going to be OS?
<kevinsawicki> DouweM: not during the beta
<tyOverby> How is atom both invite-only and open source at the same time?
<avidal> tyOverby: the engine isn't open source (or at least yet)
EDIT: Plus, if an editor is going to join the ranks of vim and emacs in history (something which neither Sublime nor TextMate are on track to do) it has to be open source. Anything else and it's just another product.
Tools work in a strange way. I recently saw a whole team of embedded developers use TextPad. They haven't heard of anything called 'vim' or 'emacs'. From their perspective its either a vendor supplied IDE or TextPad. One of them was even startled to see this shiny new thing called 'Sublime Text' when I was using it. He went out with enthusiasm, but was hardly able to convince any one to use it.
A code editor with first class prominent Github support is more likely to encourage creating Github accounts - it would just work. Compare to regular code editors which require jumping through various hoops (typically having to find relevant plugins, install them on all machines/users, and then figure out how to use them as they are extensions not core).
A pitch of "if you use this editor then all the team's work is automatically synchronized and available" is a very powerful sell.
Not for me. I do like to give new editors a try (fell deeply in love with LightTable just a short while ago), but OS X as main platform and yet another closed editor?
Others noted that the source mentioned "free during beta", I certainly hope that's not the case and it's truly FOSS. Sublime Text development has slowed significantly recently and the community can't continue to drive it since it's closed.
Funnily enough, Sublime Text was born out of Textmate development slowing, and I can't seem to shake that vibe here too.
(Light Table itself is written in ClojureScript, which is a bit idiosyncratic, but it's hardly worse than Elisp, and anyway you can write plugins in normal JavaScript.)
Thanks Github!
Seems like vim isn't really for someone like me (I haven't studied PhD level computer science and I don't write compilers and/or lisp interpreters in my spare time for fun).
My point is that I can load up Sublime Text or Brackets or this (maybe?) and work in a very efficient way.
Put another way: working with Sublime Text and Adobe Brackets is a good experience for me... There's nothing that screams out at me "Man, this sucks, I need to go learn vim."
Of course, PHP people probably said the same thing when Rails came out. The difference is that current GUI editors are already very advanced. I'm skeptical that I would get any efficiency boost from vim (at least anytime soon).
vim has nothing to do with PhD-level CS or writing compilers and/or lisp interpreters. The Emacs community might fit that stereotype a little more but really not much more.
Vi (vim being 'vi improved') is great because it works on basically any terminal. It works with my iPad's keyboard and with a teletype terminal from the 70s or 80s, as well as a normal PC keyboard. Emacs has similar brags.
The terminal's not going anywhere and if you like keyboard shortcuts, knowing five or ten that will work on any keyboard in existence for an editor that is on most unix systems you'll find has some value.
Also, I do have a mac, so maybe I'll check out vimtutor.
My point is that I'm very new to programming, and it's so much easier for me to load up Sublime Text and start getting work done. At least for now, learning vim would be something that get's in the way of learning/making. It also doesn't seem like the benefits would outweigh the cost.
I'd say give Vintage mode on sublime a shot. It does the basic keybindings/motions of vim and will give you an idea of whether or not you might be interested in it. It's also nice because in insert mode it's basically just normal sublime, so you can just switch back to that if you get frustrated.
Are you on linux, osx, windows, or something else?
If you use vim/vintage mode, remap capslock to be escape.
This took me forever to figure out, for whatever reason, but if you're on windows, the easiest thing to do is get autohotkey [1] and write a script with one line:
Capslock::Escape
You can compile that to a portable binary and use it anywhere as well. It's really straight forward.
I also added two keybindings to make Alt+movement to add cursors above and below: { "keys": ["alt+k"], "command": "select_lines", "args": {"forward": false} }, { "keys": ["alt+j"], "command": "select_lines", "args": {"forward": true} },
It doesn't always interact naturally with vintage/vim mode, though, but that was just a personal preference.
[1] http://www.autohotkey.com/
Then one day you're riding herd on a flock of zLinux images and troubleshooting boot problems through a 3270 terminal with (s)ed as your only friends.
We'll see if one of these console editors finally sticks.
Gotta keep it relevant!
[1] https://github.com/defunkt/coffee-mode/commits/master?page=7
[2] https://github.com/defunkt/textmate.el/commits/master
https://github.com/defunkt/gist.el
That said, it would be fairly simple to have a variable for super that resolves to ctrl/cmd on other platforms, the same way that most download pages nowadays infer your platform and show you the binary you most likely want.
>Atom is a desktop application based on web technologies.
This.
Also: https://github.com/substack/node-browserify
[0]: https://github.com/dnschneid/crouton
Any tricks for getting one?
> Like other desktop apps, it has its own icon in the dock
it looks like it's osx oriented.
This said, you can also write lighttable plugins in javascript.
It'd be nice to see the backend be a drop-in replaceable API so it works just as well hosted in a browser/on a Chromebook/in a NodeJS process.
That's only one piece of making an editor run in-browser and cross-browser of course, but it's an important piece.
Also -- there are actually a couple ChromeOS ports of Brackets out there already (such as Tailor - https://chrome.google.com/webstore/detail/tailor/mfakmoghean...), but I'm nto sure if any of them are being actively maintained.
On the other hand, the more the better, but we have already too many editors around.
Now I just have to master it.
I worked like that for 8-10 months then made the switch to Vim. I've gotten so used to modal editing (not to mention window management etc.) by then, that I didn't even skip a beat.
Sublime never gave me a reason to go all the way, though :p
But it crashed constantly; also, by that time the Vim emulation was really hurting me. The dot command was anemic, tabs were interfering with splits etc.
All in all, Vim was calling me, haha.
I do all my coding (though it mainly web, which arguably might need less resources than other languages) in a medium tier pc. It's a lenovo B590 with an i3, 8GB RAM. It's not exceedingly fast but with two windows of chrome, 20 tabs each, 5 or 6 instances of PHPStorm open, and all the usual programs (email clients, dropbox, chats, etc) it still feels quite snappy.
The cost here in Austria was around 650€ or so in total, maybe less (I'm not quite sure now because I upgraded it little by little).
My question is if your plans are set around a dirt cheap machine that you "wouldn't care at all" if it gets stolen, lost or broken... Or something more in the lower middle class where you'd have to be careful not to lose one per month, but you could still run most of the stuff you'd actually need for local development.
This question arises mainly for my concern is greater about not having a working reasonable internet connectivity hence making it difficult to work over ssh, rather than the laptop getting stolen or broken.
Jesus Christ, that sounds excessive.
Vim can be run well off of a $35 Raspberry Pie if that means anything to you. That machine has 512 MB of RAM. Basically every laptop will be able to handle it just fine.
So the best device to run vim IMHO it's still a top-notch SSD-based laptop. A chromebook (intel-based to avoid other sort of issues) would be a better bet.
I work this way most of the time now, regardless of which machine I am currently using: http://blog.schwuk.com/2014/01/15/chromebook-plus-digitaloce...
Some of them look quite interesting already.
It looks like the GH guys have worked around this problem quite well, and I'm looking forward to begging, borrowing, and then just begging again if I get a chance to try it out.
Not sure if that's an unfounded fear, but I don't want to invest time customizing a platform and writing plugins when it could close shop in a second. I suppose I could say that about a lot of things I do customize, but it's hard when the FOSS text editor world is so rich.
On top of that I can be up and running with Emacs on a fresh install of just about any linux distro: install via the distro's package manager, drop in my configs, done.
It is fast enough for every job I've ever thrown at it... Do you only want there to be one programming language or something.?
This coming along scares me that an already tenuous situation around the future of Sublime Text may implode due to this new editor... and it isnt even open source. I'd rather build my own highly customised GUI+CLI macvim/emacs with both python and JS plugin backends than switch from one closed source editor to another just because its new and uses Node... I dont normally swear on hacker news ... but fuck that shit.
http://atom.io/packages/metrics
BTW, I'm less concerned and more just surprised to see Google Analytics used like this. I guess it really is the blurring of the lines between desktop and browser-based apps.
Maybe this GA usage is not unique, but it's new to me.
You are, though it's mentioned on the very first screen that pops up when you open the app: https://github.com/atom/welcome/blob/master/lib/welcome.md
My only question is -- why should I switch to this from Sublime Text? Are there specific use cases it handles better out of the box, or is it more of a modular base that will be expected to grow and outfeature ST2/3's seasoned plugin economy? I am very happy with Sublime Text now, but I would be willing to switch if either it gained a lot of traction, or could do stuff that I couldn't do with Sublime.
I'm blown away by how cool this is. I'm just really hoping for good Vim keybindings and I will pay good money for this once it's out of beta.
I was given 3 invites, I gave away 2 but I'll give the third to the first person to email me. (EDIT: gave away the last one)
Doesn't seem like they're keeping too tight of a lid on it, but I guess we'll see. It seems like it can be freely passed around; I think they're just trying to gauge interest since it won't be free after the beta period.
Vintage mode in ST2/3 isn't perfect, but it's pretty solid.
Atom looks interesting. I really look forward to trying it out.
I'll have to try that out again
Other than that, it seems like an incredibly well-designed editor. Really looking forward to seeing what happens to it now that it's out in the open.
I also expect NPM to be much better in practice than the sublime package manager which frequently ships broken code. JS is a better choice than python for async code which will make writing plugins easier.
Furthermore, ST is 3 people who largely ignore all feedback from the community regarding bugs and features. It won't be hard to out compete ST in the long run.
In terms of ease of development, the order goes like this: IntelliJ ~ Emacs > Sublime ~ Ace >> Vim. In terms of community and support, the former ordering is also true.
POLLING:
Here we are trying to get the Window, from the Sublime API. Sometimes it doesn't exist (even when windows are open). There is no reliable API to tell us when new ones are made or when old ones go away. Presumably, post_window_command (http://www.sublimetext.com/docs/3/api_reference.html#sublime...) would fire off with a close command, but this function has never worked.
https://github.com/Floobits/floobits-sublime/blob/master/flo...
Here is another quick hack polling the editor to know when its safe to call the sublime API: https://github.com/Floobits/floobits-sublime/blob/master/flo...
Here is a yet anther example needed for functionality and using callbacks to keep sublime from crashing: https://github.com/Floobits/floobits-sublime/blob/master/flo...
Here is another example of pure craziness forced on us by ST3. We need to patch Views, but ignore our own patches (locally) so we don't form an echo loop. We also need to move the cursor so it doesn't jump. Sublime deals with these changes so poorly, we are forced to jump through hoops. In contrast- emacs/vim/intellij are basically fine just dumping on the entire buffer.
https://github.com/Floobits/floobits-sublime/blob/master/flo...
I would love to see ssl compiled in - I believe the reason Jon currently doesn't is that it would require building on at least 6 different machines to cover 0.9.8 and 1.0.0 (libssl.so.10 and libssl.so.1.0.0) for x86/x64 plus a customized version of ssl.py.
I guess it may be that my google-fu is just sucking lately, but the docs situation seems bad after a few weeks of using it. If I'm wrong and anyone has any suggestions, let me know and I'd really like to check them out.
The moment that their new editor provides some piece of Github functionality that isn't exposed to an open API is the moment that we need to bail, en masse.
We've already killed Freshmeat and Sourceforge for turning lame, this shouldn't be hard.
What other text-centric apps can be made better by a browser framework? Maybe the terminal?
It's not a good idea, but given the abysmal state that desktop apps seem to be in at the moment[1], it's probably the least bad idea.
[1] Been about 5 years since I did a desktop app, but if anything they look to be getting worse. WPF, flop. Flex, flop. GTK+ looks poo. If I had to do a cross platform desktop app, I wouldn't even know where to start.
Dunno about cross-platform app development, but Cocoa on OSX is pretty nice. QT isn't bad either, from what I've tried.
> text display, scripting, styling
The only thing that really matters is scripting. Every serious editor has solved displaying text and styling since ages and those two points aren't even that important in programming languages. All you want is a syntax aware highlighting. Maybe underlines and a little bold here and there.
Scripting is the really hard part. There are many flavors, languages, APIs to chose from. Just because you now can script things in <hip-language-of-the-day>, the problem isn't solved. My editor uses a lisp dialect and I'm perfectly happy with it, not because of the language choice but the APIs and amount of integration.
One thing that is incredibly important for text editors is speed: something web engines are notoriously bad at.
Because most websites use contenteditable for their rich text editors, which is horrible to deal with. It's not standardized, it gives developers very little control, and its output and capabilities vary a lot from browser to browser.
Web rich text editors that don't suck - e.g. Google Docs - bypass the browser's support for rich text editing entirely. This makes them usable, but it also means everything has to be implemented from scratch, so the code is complex. AFAIK there are no general purpose rich text editors built like this that are open source or even licensable.
There are some pretty good non-contenteditable code editors, though. Presumably Atom will be built in this style.