I wonder why it wasn't this way from the get-go... Oh well, at least I'm actually interested in it now. Can't wait for the Linux version to try it out. Pumped that they did the right thing and open-sourced it so that it actually has a chance of becoming widespread, and more importantly, of sticking around for longer than a couple years.
At the risk of being too cynical, I suspect that they're open sourcing it because their analytics indicated an adoption rate that wouldn't justify active development. Not sure if this is still the case, but the Atom.io website, at one point, indicated that its price would not be free, but would be competitive with similar products in the market (I'm assuming Sublime Text).
Definitely not (the beta's been great!). We've been discussing this ad nauseam for years and years, with some good points on both sides. We were looking to make it a partially open, paid app when we launched the beta, but after continuing discussions internally the Atom team decided to go the fully open source route.
Yeah, no conspiracy here. Sometimes when people say they're going to have a beta to gather information and make an informed decision, they actually do it.
edit: Not meant as a hostile remark, seriously wondering how it's going for people who have stuck with atom. I tried it for 5 minutes, but didn't give it a real commitment.
I tried replacing Sublime Text with it, and got quite into it.
I however fell back to ST for a number of reasons.
Speed - ST is just quicker to get up and running.
I found a (large) file or two that atom just could not deal with.
State - I can CMD-Q ST with no nags, then re-open to my previous state when I want. I generally have a number of useful scraps open at one time, so not having to save these is great, and not losing them when I close the editor is just brilliant.
Visuals - The open file code overview on the RHS is a must have for me.
Muscle memory - I just kept opening ST from the terminal, and had to go through the process of closing ST and opening atom. This could have been mitigated by re-aliasing slt, but that's a commitment.
I do wish ST would automatically include the directory of the file you are opening in the project like atom. Brilliant when you are just flicking through source. Open one file and then not have to leave the editor to go to the next one.
There was also something funny when I opened a squid cached js file - I could highlight and copy the text, but whatever was copied to the clipboard was not what I had highlighted. Think highlighting and copying in general is still a bit beta.
That said, I spent some time tinkering, and loved the open nature of the plugins.
The bracket matcher plugin does both highlighting of brackets and auto closing. I hate auto closing. It took all of 15 minutes to work out the plugin architecture, disable the offending plugin and hack in the parts of it that I liked.
In my books that's a winner. I may even pick it back up if it is going to get real love from the community.
I've been using Atom as my main editor since the beta rolled out. I love it - it has the (very) occasional quirks and glitches which you have to forgive as it's in beta, but once you get used to navigating around, it's really fast and fun to use.
Now that it runs, it feels pretty responsive and you can customize a lot of stuff. I haven't used for coding yet, but will try it out for that in the next few days.
I primarily use RubyMine day-to-day, but Atom has become my text editor of choice. I just really enjoy having the ability to hack my editor using technology I'm already familiar with.
But how can putting this functionality into an extension package be considered a reasonable design choice? It isn't an editing "component" like e.g. Scintilla, it's meant to be a general purpose editor: offering a decent out-of-the-box user experience and providing a sensible foundation for extensions should be two of the top priorities.
Because you can then separate out what re-sizing is. Maybe you write a plugin that lets you drag with a mouse to re-size, but maybe someone else never uses their mouse, and would prefer a re-size plugin which auto re-sizes everything according to a tiling layout similar to a tiling window manager.
Separating it out has a lot of advantages, especially by not putting in much opinion by default.
> But how can putting this functionality into an extension package be considered a reasonable design choice?
I like the design of Atom, because it allows me to freely compose an editor that does exactly what I want, and nothing more. While multiple panes is a requirement for bpicolo (and you?), I use multiple panes in Atom (my primary editor) and haven't felt the need to resize them. Am I the minority, or are the others? Or is it 50/50? Basically, we don't know until the editor has time to grow, and its community has a chance to dictate what features are required.
That should be pretty easy. As I recall right, Sublime is a really basic core (we're talking notepad.exe levels), and various core plugins actually make up the main functionality of the application.
@Jormundir me.. for a little while now that something messed my sublime installation and I did not bother checking what's wrong. most likely a simple config error but atom's been more than ok to be my daily driver.
You're not too cynical! I'm in the same thinking boat. The first thing that that I thought about is either they don't want to do it anymore or the adoption rate was not what they expected.
They made it perfectly clear that it will not be open source and it will cost money. I don't think they need 10 weeks to understand the benefits of open source.
I like the idea of knowing whether people are actually using a feature or gesture that I as a developer thought, but was just guessing, was so important. So that I can remove or improve it.
(I'm not an atom developer. I just envy being able to make decisions in the context of data, having spent most of my developer life without it.)
Mostly the VC-backed web stuff, where folks coming from the web don't seem to understand that explicitly and unnecessarily contacting a server to push analytics is very different than recording the requests that web browsers make by virtue of their operation.
Ever see that questions when you first start your phone, or MS office, or Google Chrome, or OS that's like 'Over time we like to collect anonymous diagnostics and usage information. Yes or no?'
When it's done by software running on hardware you control, it has to consult your hosts file and your iptables and your proxies and your routers. Ultimately it can't do anything you don't let it. You don't have to opt-in to paying attention to the connections each program makes, but you also don't have to willfully ignore them.
If you care about that sort of situational awareness, there are tools like Little Snitch that make it easier.
As I saw it, GitHub was trying to see if it could become a business. Developers will pay decent money (as in "desktop software" money, not "mobile app" money) for a quality text editor.
I wouldn't have blamed them for going commercial, but I'm happy to see them releasing this to the community. :)
I paid for Sublime Text, and there were enough rough edges and bits I didn't like about both vim and Emacs that I felt justified in paying for it, but nevertheless seeing development slow to an absolute crawl on a product I paid for makes me nervous.
If you still feel like maybe vim could be something for you if the rough edges were removable, come talk to us at https://github.com/neovim/neovim in a couple of months when we'll be ready to start implementing new features. The refactoring is going great and work on the VimL -> Lua(JIT) translator is already quite advanced.
Neovim seriously has me so excited that I could scream like a little girl.
On a list of software projects I wish existed, a modernized Vim would be numbers 1 through 10. I enjoy core Vim, but the pain of Vim's limits when adding in new functionality with plugins (like pauses running Syntactic checks, or the hiccups and lack of smoothness of every autocompletion plugin ever) are a downer.
The biggest pro about Vim[1] is that I can open a hundred instances[2] without having my OS gasping for oxygen. I would very much love to see a modern UI, a clean plugin interface, etc., but I fear that those changes would make Vim as heavy as the competition.
I wonder if Emacs will eventually compete, though, both UI-wise and for cleaner plug-ins.
When I am done working on something, and want to start working on another project, I don't close the previous project. I leave it in a virtual desktop. That way, when I wish to resume work on that project (or component of a project), switching to the correct virtual desktop is way faster than opening the console, going to the right directory, opening Vim, and opening all the relevant files. Besides, the local shell history is also ready to grab to start running all the tools I need for testing, debugging and general dev aiding.
Project switching, I find, is really hard, but it is made way harder by having to remember all the unique locations of files, directories and commands related to the project, and having to wait for everything to load.
I really like Sublime's workspaces system as a solution to this problem.
If you have a project open and need to switch to another one, Ctrl-Alt-P opens the project switcher. If you switch to another project, the previous project's workspace is saved. So when you come back to the last project, everything is JUST as you left it.
Alternatively, if you need to have it open in another window (for comparisons or whatnot), just open a new window before opening the project switcher! (Ctrl-Shift-N, Ctrl-Alt-P)
Vim already has support for Lua, although you tend to have to compile from source and enable that option as most distribution packages don't have that option enabled.
I can't speak for the other poster, but in my case gentler learning curve (I've been using vim for about 10 years and I still don't know 10% of what it can do), smooth scrolling, a real GUI (vim's text menus can be pretty confusing at times), and the features vim didn't have at the time like multiple cursors, command palette and go to anything.
Why do I keep using it? Because generally new functionality requires about 2 minutes of readme.md and then it is working, rather than half an hour of hacking with vim config files.
Overtime I just found myself being more productive and 'happier' while using Sublime. A lot of that comes from the extra functionality it offers (built-in and from numerous plugins). Eg, Markdown preview, image preview, color picker, various project search and management features from SidebarEnhancements.
I still love Vim and use it for editing single files or whenever I remote in to another machine but this new generation of text editor / IDE hybrids just fit my project workflow a bit better.
I'd say there's always room for a product that works well. Textmate, back in the day, had to come in and compete with well-regarded software after all -- even if we ignore vim/emacs as being insufficiently-Mac, there was BBEdit.
I don't know that I'd say Sublime users are "stuck". The long beta on v3 seems to be splitting the community, somewhat, but it wouldn't be surprising if the final release resulted in it consolidating again.
Perhaps, but either way as a ST2 user I'm looking for a replacement and once ST2 does not meet my needs I'll either go back to emacs full time or look towards something else for light weight stuff.
I've already movers most of my we stuff to IntelliJ/WebStorm. I really liked ST2 but was a little miffed that right after I bought my licence ST3 was pushed to the forefront of the site without a reasonable upgrade plan.
I do certainly agree that the new-version / upgrade thing has been poorly handled. If nothing else, announcing it and causing the split should have been followed by rapid development instead of over a year of slow beta releases.
it would a LOT be better if there's a deb package available, you have to do a lot of tweaking to make node work as `node`, since it's named `nodejs` to avoid package name conflict in Linux
now that it's open sourced, am sure it'll take like a second for someone to release the deb package
I wish people would just use OpenSuse Build Service! https://build.opensuse.org/ If you build it there you can make it work for Ubuntu, Fedora, Cent, Debian etc... The must under used Linux tool in the world!
OBS really really needs a nicer tutorial and/or an "import from GitHub" button. Getting artifacts into my OBS project (or was it OBS Home?) was pretty tricky
That (which can be fixed somewhat easily by [1]), and they rely on version >= v0.10.* which is gross as only v0.6.9 is provided by the default Ubuntu 12.04 repos (which are what is recommended by their README).
yep i can and i did, still, I'll like it far more if it `just works` without me having to open the terminal and install node, npm, make link of nodejs...
Did anybody manage to get this working on 14.04?
I got past the initial node-vs-nodejs problem, then got loads of errors on script/build and I can't go any further.
I assumed they wanted to limit the amount of feedback/bug reports they got to a level they could usefully cope with. Any new release is potentially going to have tons of issues with real world situations that never happened for developers or in QA. Anything released by GitHub is going to get a lot of attention. By limiting the number of initial users, they can get some real world testing and not get millions of duplicate bug reports.
Also, releasing something open-source isn't as straightforward as it may seem unless you've started that way. Think about all the internal libraries that developers might have used or all the security or licensing aspect of it. There are lots of stuff I would love to release open-source but I just don't have the time and I'm too much of a perfectionist anyway.
> As Emacs and Vim have demonstrated over the past three decades, if you want to build a thriving, long-lasting community around a text editor, it has to be open source.
I agree whole-heartedly. In fact, I don't believe that editors like Sublime Text would have such a large following if not for the extended "free-trial" functionality.
It will be exciting to see where this project goes, and I think open-sourcing the rest of the editor was a great move.
Agreed, amazing news. This is the announcement I've been waiting for. I've long been worried that with a closed source core, the editor would of fallen prey to the same issues that plague closed source editors. With that out of the way now, I'm excited for what atom will become.
You're confusing "free" in pricing with "free" in freedom. A free trial creates a completely different type of community than free and open code. GitHub could have just provided a closed binary for free if they wanted to go the Sublime route.
Interestingly, Tom Preston-Werner (former CEO of Github) said in February that Atom wouldn't be fully open-source:
“Atom won't be closed source, but it won't be open source either. It will be somewhere inbetween, making it easy for us to charge for Atom while still making the source available under a restrictive license so you can see how everything works. We haven't finalized exactly how this will work yet. We will have full details ready for the official launch.”
- Tom Preston-Werner, 27 Feb 2014 http://discuss.atom.io/t/why-is-atom-closed-source/82/9
Please don't say 'fully open source', as it confuses the language.
"Open Source" is a well-defined term[0] . What Tom Preston-Warner describes there is basically the same as Microsoft's "Shared source[1] " licenses, which do not fit the definition of Open Source.
Of course chimeracoder noticed this. That's what he was talking about. Because "open-source" is a binary condition, being "not fully open-source" is like being "not fully pregnant" — the phrase is just an equivocation that ultimately means the same thing as "not open-source."
I don't think anybody would ever say a family with three daughters was "not fully pregnant." You would say some members of the family are pregnant and others aren't.
And anyway, this wasn't the sense in which Preston-Warner used the phrase — he did describe what he meant, and it was not open-source software. It was, as chimeracoder said, similar to Microsoft's "shared source" program.
Is there any chance this change of heart has to do with his departure? Perhaps the team always wanted to commit to being fully open-source, and he was the blocker.
Or perhaps GitHub wants to salvage their reputation in the Tech circles by doing "something good" without too much business loss (selling text editors probably isn't very good business).
GitHub's reputation is conflicted at the moment. It has had a lot of support, but some events do raise warning bells. Only time will tell whether they are actively ensuring their work environment is something I will continue to support. The exit of Tom is a good sign, but since we can't know what terms there were, the only logical thing is to hope they are good to their word.
You are conflating the reputation of github the company that provides services to hackers and github as a place to work. Entirely different reputations.
And that's an example of the multitude of different 'colors' of consumers. Card's comments kept me from purchasing his stuff. I read it, sure, but I sure as hell didn't purchase it.
Some people don't partition the reputations of corporate 'entities' into separate walks of life.
Salvage their reputation? Are you talking about that inappropriate behavior by one of the cofounders incident? Because if you are, consider that you may be significantly overestimating its influence on the elusive "tech circles".
Also makes me much more trustful about the openness of Atom. Much better than the closed development processes that I usually see from big corporations (e.g Google, Apple, Samsung, EA, at their respective open-source websites).
> As Emacs and Vim have demonstrated over the past three decades, if you want to build a thriving, long-lasting community around a text editor, it has to be open source.
Using a free software license is a big improvement, but I wish that they used a copyleft license like the GNU GPLv3. Inevitably, we'll see proprietary extensions and "pro" versions. Strong copyleft is important for the freedom of end users.
The GPL doesn't prevent the proprietary extensions and "pro" versions, it just prevents anybody but the original author from making those pro versions.
Therefore companies who want to make their money selling pro versions usually choose the GPL license. So in practice, we see more "commercial/pro" versions of GPL software than we do of MIT/BSD licensed software.
It prevents the "original" author from making those versions unless he or she requests a transfer of copyright for any outside code. If you have evidence of the second claim, I'd love to see it or see a link. (I mean this as non-confrontationally as possible; I don't have an opinion one way or the other on whether it's true, but now I'm curious.)
The standard example of this practice is MySQL. If you want some more, Google for "open core". Warning: you'll probably run into many heated arguments.
> GPL [...] prevents anybody but the original author from making those pro versions.
This is only true as long as they accept no 3rd party contribution. In this case, accepting 3rd party modules is a crucial feature, so GPL+commercial wouldn't fly.
A copyleft license would not preclude this, as the Atom authors would still hold copyright, and could freely distribute a "Pro" version under a proprietary license.
A copyleft license would prevent someone else, who does not hold copyright on Atom, from doing that.
So you're happy that the original authors use copyleft+proprietary instead of allowing anyone else to release a fork (which would also be free software)? How's that better?
This is called "open core" strategy and few companies use it correctly because there is so much incentive to focus development on the "pro" version and let the free/open one stagnate (or lack basic features).
I wish they had it released under a less restrictive license like BSD or MIT.
Well, it's also very difficult to justify contributing to a project that's open core because it means assigning your copyright to someone who stands to profit from your work while denying you the same right. There have been projects that have managed to still get contributions under this model [1], but they're probably the exception rather than the rule.
Of course, then when you don't get any contributions that only feeds the justification for focusing on the paid product, because clearly "the community doesn't care".
[1] mysql is the biggest and most obvious example, but it seems like a lot of tension built up over it and that's resulted in several forks existing now. Who presumably accept contributions without attribution to Oracle.
I forgot that the first line of the GPL reads "YOU MAY NOT SELL THIS FOR PROFIT". It's a shame there are no billion dollar companies based around the GPL... /s
> It's a shame there are no billion dollar companies based around the GPL... /s
There is and it is called Google. It's a champion for Open Source and seems to use Open Source software almost exclusively across their entire organisation.
Plenty of businesses depend on FOSS desktop software, it makes them money. If I use Linux and tools like Blender, Vim, GCC, etc..., and I sell the resulting product, then I'm making money with FOSS, am I not?
Copyleft licenses just make sure that people that want to get paid for their work (a legitimate venture) don't just piggyback on the collective effort of open source projects.
Perhaps we will. I strongly doubt any of those will be even a slight success, unless released by the Atom team (which the copyleft license wouldn't affect).
Well, I'm glad for the closer to public domain MIT licensing.
I believe that the ability to sell it if you hit a home run leads to a lot of big ideas getting tried and the base hits making their way back into the open codebase.
But I think it is a matter of taste/personal preference. For me, copy middle feels more free.
The editor I use now (Epsilon) was last significantly rev'd about 8 years ago. It's a fine editor, but I'm starting to look for a replacement (and, oddly, I cannot stand where modern Emacs went).
Sublime Text 2 is darned close. If only I could teach it proper bindings of C-U . . .
Not really surprising - the whole idea of web desktop apps is kind of crazy, especially for something that you want to have good performance like a text editor.
- Having Emacs suspend the shell I'm working in sucks
- Getting names of files to actually appear as buffers, without extra gorp like a listener window that I don't care about at all is an exercise in frustration
... and more, but I need to find the last .emacs file that I spent half a day hacking up for details (and don't get me started on the geometry nonsense you need to control where Emacs starts up and how big its window is, and how well this plays with environments that have different monitor sizes and . . . oh bog, it can be better).
Inevitably someone's going to argue about how Emacs should be used ("you're supposed to get into it and never leave" and similar nonsense), or point out that I can customize away the things I hate. True. But I've been using Emacs since 1979 or so, and it just seems much worse in the last ten years.
I probably would've been inclined to argue about how Emacs "should" be used, but I'm not about to presume so with someone who's been using it for two years longer than I've been alive.
If you're inclined to amplify on your perspective of how Emacs has changed over time, I'd be delighted to hear anything you have to say on the subject. It's so much more powerful than anything else I've ever used that I'm still very much in the honeymoon phase despite having used Emacs as my sole editor for almost a half decade now; I would value most highly the privilege of hearing from someone with a more experienced and balanced understanding, such as yours.
I'm not entirely sure I follow. Is it that toolbars and menubars themselves suck, or the particular ones in emacs? (fwiw, I have them disabled and don't feel like I'm missing much. Reenable them every now and then to explore the "promoted" options of modes.)
I'm inclined to agree with the shell thing, though that is more of a property of the shell, isn't it?
And you've lost me on the names of files. What do you mean?
I certainly don't think you are using it wrong. I am extremely interested in how things have gotten worse. In particular, examples of how things were better would really help to understand. (And, no, you don't owe this to anyone. I would appreciate it, though.)
Failing that, backgrounding the process at launch (by appending & to the invocation) should stop it blocking the shell from which it's launched.
While I did mean what I said earlier about not feeling qualified to argue with someone who's been using Emacs since before I was even a gleam in my father's eye, I do want to point out that it's maybe sort of unfair to blame this one on Emacs; any process you launch from a shell, which doesn't immediately perform a detaching fork from its parent process (as most things don't), is going to have the same effect, and require the same modified invocation to prevent blocking your shell.
Pleased to read this comment. Reading Hacker News gives you the totally wrong impression that the text editor universe amounts to Emacs/Vim and Sublime/Textmate. There are a lot of other editors, many have a lot to recommend them. At least on Windows, Ultraedit for example seems a lot more polished and complete than Sublime.
I think we have. Debuggers are highly language specific. It's just easier to have a separate debugger for each language.
I think it'd be nice if some of the IDEs gave up on forcing everything into their project structure. There's a real market for stand alone visual debuggers that don't try to manage your entire project.
But that was the whole point of an IDE: it integrated the development environment, piecing together the editor, the compiler, and the debugger, taking advantage of intimate knowledge of the specific targets. Why are we suddenly calling a text editor an "IDE"?
> Why are we suddenly calling a text editor an "IDE"?
I suspect because lots of developers actually use those text editors as their main development environment. So they have the D and the E parts of that equation covered.
Also since these editors tend to be highly configurable, with a bit tweaking the user can make the editor do a lot of the I as well.
I also use a text editor as my primary development tool, yet I do not call it an IDE. I repeat: the whole point of an IDE is to be a truly integrated development environment, piecing together the editor, the compiler, and the debugger, taking advantage of intimate knowledge of the specific targets. If you don't have an integrated debugger, you are not using an IDE. There is no shame in that, but it still doesn't make any sense to be calling the tool an IDE unless it, well, is an IDE. It seems like the more useful thought is then "people seem to have stopped using IDEs as much", not "IDEs have given up on integrating features like the compiler and the debugger"... if you aren't integrating the compiler and the debugger, we already have a word for that: text editor.
I think some people (including myself) prefer to get something barebones and add plugins/addons/extensions to get just what we need.
I can run some monolithic IDE like Eclipse that comes with everything I need plus a bunch of stuff I'll never use or I can take Sublime Text/vim and add just the right combination of packages to fit my needs.
You have also described me; I do not feel the need to call Vim an "IDE". I even appreciate that it can be turned into an IDE (though I do not do this: I currently prefer to use separate tools), but it doesn't become an IDE until after you've added enough plugins to have covered the functionality of at least "compiler" and "debugger". In essence, I'm confused by your response, as it seems to indicate that "because some people don't want an IDE, they choose to call things that are not IDEs using the name IDE".
Slickedit integrates itself with lots of debuggers so I'd assume given enough interest Atom could be made to as well. Besides, given it's based partly based on chromium you could use the chromium devtools as a starting point and try to adapt them to multiple languages.
Being hackable, I presume that integrating a remote debugger should be possible.
Vim can already technically do it - just that most people who cared about integrated debugging were probably using emacs.
Javascript has been the biggest waste and diversion of programmer talent since computers were invented. Billions of dollars have been wasted trying to fit every square peg there is into a Javascript round hole, and the sh*t still continues.
Even after 20 years Javascript UIs can't match stuff done 20 years ago on native UIs.
Whatever happened to the notion of cost-benefit analysis?
Is there ever going to be some professionalism in the programing profession, if in its current state it can be called a profession?
How much effort is the industry going to put into implementing software on the Javascript/HTML combo which is, has been and will always be under-specified for what programmers want to use them for?
PS. It seems that every other article on HN relates to an attempt to hack some complicated stuff on top of an ill-suited Javascript/HTML combo. Is there some connection here?
You should only be embarrassed if you continue to beat up on it in light of the new information. Otherwise, if your arguments were correct and valid at the time, there's no reason to be embarrassed.
Atom Shell is a runtime environment that you can write your own Node-in-a-web-browser apps against, yeah. Atom-shell is the C++y bits to provide some of the APIs that are available in JS.
Its got a _long_ ways to go before sublime has anything to worry about. The plugins and language support Sublime has is its real asset. I'd be happy to make the switch when the feature parity is there, because I'm not too happy with the way Sublime 3 has played out, but that day is a ways off.
Just really poor communication in regards to status, it blew past the 2013 release window without any status update from the developer. The product is great, just feels poorly managed. It leaves me with an unsure feeling in regards to the future of the product.
That's true. I used to be an emacs fanboy (1) until one day came along textmate with snippets, tabs and "sub major modes" (don't know how to call 'em - take for example php inside html or such). Then I switched to sublime text. Now both editors are stalled... I might switch back to emacs.
This is an interesting reversal for Github. The original FAQ implied that Github would try to market Atom commercially. I'm curious as to what made them change their mind.
>The original FAQ implied that Github would try to market Atom commercially.
We were leaving all options open during the beta.
The adoption rate was incredible (contrary to suggestions to the contrary), and in the end the Atom team decided the best thing GitHub could do with Atom is give it to the community - not because of any sneaky reasons, just because that's how we believe it can do the most good in the world.
Installed on Linux Mint. Some minor UI problems here and there. But that's nothing compared to how bad autocomplete is. At least for PHP development it's unusable at all. Because of that even had no intention to check further. But for those who wonder - yes, it works on Linux.
I'm pretty excited about Atom Shell as it looks like they fixed the different js context problem that node-webkit had. The last time i tried node-webkit i was really annoyed by the sneaky bugs that pushing objects from one context to the other introduced.
Maybe someone will implement the UI without a Node/CoffeeScript backend? Memory usage has been pretty abysmal in my trials (though we've got some very large repos).
I'm definitely with the group that they 'opensourced' this because they had to... I know my entire office went from 'fuck-yeah' to '.... meh' to 'what? yeah, I forgot about that' in about two weeks time.
I mean, it's still damn good of 'em I just hope it gets some love. I'd like to see more competition in the space, but right now I have a feeling it's just going to be abandoned before too long then I'll be knocking on the door of ST3 or Vim again.
IMHO Tom (now gone from the company) always held a strong opinion to open-source ALMOST everything.
From the outside, looking at the conversations that took place on Twitter after the initial release, he seemed to have a strong opinion on Atom being the same way, core inside github and rest is open-source.
Now that he's gone, that limitation is off and it's open source as it should have been from the get-go.
There's absolutely no reason this product won't be open source to the core, the more people actively developing on it the better.
Me personally, I haven't used it and I don't see myself using it ever in the future, but it seems like a very nice concept project.
Can someone comment on whether it's feasible to port Atom to function in-browser? Seems like this + something like Codepen could potentially be an asset to frontend developers.
Alright, now I need a comparison of how Atom compares to Sublime Text, Light Table and Emacs (and maybe even Vim, but its moded editing makes it a completely different beast).
Upon its initial launch, most of the criticism around it pertained to it not being open source. I think we can certainly expect to see its growth overtake that of Sublime Text, and I'm interested to see how the community interest will stack up against other open source editors like Light Table.
Hopefully Atom may join the legendary ranks of Vim and Emacs.
$ git clone git@github.com:atom/atom.git
Cloning into 'atom'...
The authenticity of host 'github.com (192.30.252.129)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'github.com,192.30.252.129' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Looks like their README reflects the fact that anyone who could see the repo could also push to it. You should submit a PR :)
EDIT: I am mistaken. I thought cloning git@ meant you could read/write from it (aka allowed to push). Turns out it's just a public key thing. Comment above me is correct.
Everyone knows the rules by now. If something awesome comes out that's not FOSS or even only partially FOSS (dual license, etc) just ignore it until it's either cloned or fully opened.
Follow this algorithm for an open net. Profit margins get pretty tight tho
Fun! A few days ago I mentioned I wish Sublime Text could have preview panes, but it only does text. [1] This editor does just that! Unfortunately it's very sluggish. Which also ties back to a comment about another HTML5 text editor. [2] I want to love this editor so bad, but I'll wait until the performance improves.
I don't get why people keep creating new text editors. Emacs exists, people. And it is a great text editor. These new editors look pretty and do work, but they don't even come close to Emacs. Instead of re-inventing the wheel, why not just take Emacs and add a pretty face to it?
Well emacs last stable was March 11, 2013.
I use emacs on my headless servers and it's perfect but if you really want to work with it you loose time.
Take any big project you want to open a file from emacs you have to know the exact path, with atom (and sublime text) you just type the name and you get suggestions. Plus you can still use emacs shortcuts if you want.
Yeah emacs is good and useful but it's almost 50 years old it's like telling us "why would you want a nexus when the 3310 already exists?".
No, you take the core of emacs and add a pretty shell around it that adds these features you are talking about. Such as quick way to open files, and so on. There is no need to re-invent core text editing.
I am really stoked for a Windows version, which in turn will mean I will move on from Sublime Text Editor 2 onto Atom. Unless of course Sublime Text Editor 3 comes out before then. Tried Atom on a friends Mac, a really solid editor that I am excited to see what the future holds for it.
Masivo props to Github. They just almost assuredly made this editor long-term. What was once a cool tech-demo is now probably going to go mainstream for everybody. Wow.
I just can't imagine a behemoth like Github not injecting itself into Atom for the better.
I wonder if this was partially because they considered the effort involved to develop a Windows and Linux version, plus the amount to get the performance where people would like it, and then decided it's not worth it? At least commercially.
I'm delighted to see Atom open sourced. I tried it out a few weeks back and came across a bug where the editor would lock up when a few empty files were created. Then I couldn't dig into the code to fix the issue but now I can.
I wonder if the way that atom was built is or can turn into a good way to build modern cross platform desktop apps while employing web technologies. Does anyone have any input or actual experience with this?
If you know node backend and web front-end, there are at least two options right now:
For a self-contained, deployable desktop application use `node-webkit`. It is basically chromium + embedded node.js. From what I'm reading, atom-shell is similar to node-webkit. There are a few other `node-webkit` like projects on github.
For lighter deployments, where your audience already has chrome and node.js installed, try `node-chrome`. It's a skeleton to run a chrome packaged app locally which communicates over websockets to a node.js service you build.
Both of these are good options if your UI, notifications can be contained in HTML. Challenges arise when you want to use OS specific integrated menus, growls/notifications, tooltips, etc. Node-webkit may have addressed most of these by now.
It always makes me chuckle when I see companies trying to ship a product (free or not) and realize a few months later that it's not picking up adoption. Then they decide to open source it in an effort to make it popular but of course, they can't admit that, so they always come up with excuses like "We want the community to benefit from it" or "We really believe in open source", etc...
In the end, for most of these products, open sourcing is usually just the last step before the product dies.
That doesn't seem to make sense here, as Atom was still in open beta, and they haven't released the versions for roughly half of their user base yet.[1]
about this, I use brackets, a lot of it does look like brackets maybe with some ideas taken from light table http://www.lighttable.com/
There's a thread on discuss.atom.io about what distinguishes the two http://discuss.atom.io/t/what-distinguishes-atom-io-from-bra...
I guess I don't feel atom does enough different from brackets that I can justify switching editor at this point, but if anyone has more to add than was found there I'm interested to hear.
They don't have official builds yet. If you care enough you can build it. They'll get official builds probably soon enough. I don't know what you're complaining about..
I think it really speaks to the crowd they are courting with atom and I don't think it's the right way to go. The traction they are looking for will never happen if they have a darling platform.
What steps did you take to get it running on Arch? I got as far as convincing it to use python2, but then realized I need gnome-keyring, and kind of stopped there. Which keyring package did you install?
You are absolutely correct. I meant to say copy left license. I stayed up way to late and woke up way to early. They do say being tired is similar to being drunk... ugh.
I'm still trying to find out why a great company like GitHub would shamelessly copy Sublime Text 2. It's one thing to say we need to build another text editor because nothing out there gives you what you need. But to say we need another text editor and then copy Sublime... What the heck is that?
I installed it today for the first time because this was the first time I didn't need to be in a special club to use it.
I opened a directory of source that ST opens instantly. This thing took 5 seconds to open. Then when I quit the app, I get an "Editor is not responding." message. Everything feels sluggish.
Atom is no more a shameless copy of Sublime Text than Sublime Text is of TextMate.
Having said that, I do agree that the sluggishness of many of these "modern" editors (including Sublime Text, which even at ST3 is quite a bit slower at opening large files than it should be) really is quite a shame.
This isn't a copy of sublime. The fact that it effectively runs in a browser opens up all kinds of possibilities. Insert an inline IMG, canvas, webgl, video, svg. I'm hoping to see some amazing extensions from this
Good on you, Atom.io devs