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.
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.
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
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...
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).
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 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
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.
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.
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.
> 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.
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.
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 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.
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.
@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.
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.
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.)
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 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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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?
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.
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).
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.
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.
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.
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
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).
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".
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.
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.
$ 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.
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 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.
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.
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.
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.
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]
307 comments
[ 3.6 ms ] story [ 127 ms ] threadhttps://github.com/atom/atom/issues/1931
but finally got it building on 12.04LTS
The Atom Shell open sourcing is also interesting ... I wonder if it will lead to a rash of other Chromium-fork-apps
---
There are builds for atom-shell for Windows and it gives you something that looks like this: http://imgur.com/H0RcGc5
I haven't understood what you're supposed to do with it yet (I thought it was just a library).
OT: Fullscreen and windowing is nicer in Windows... In OSX (@home) everything feels sluggish with the overflow of animations...
The docs for Atom Shell are pretty good, have a look at https://github.com/atom/atom-shell/tree/master/docs to get started
I was really happy to see that post from Kari the new PR person, but no more word after that... http://www.sublimetext.com/forum/viewtopic.php?f=2&t=15477&s...
TBH I just want window background transparency and I'll be snug as a bug, all other updates are meaningless
It looks pretty open to me. However, I don't speak legalese, so I may be misunderstanding it.
https://twitter.com/shit_hn_says/status/463711610172088320
The legalese is translated into bullet points in the right-hand column.
>Today, we're excited to announce that we are open-sourcing Atom under the MIT License
Good on you, Atom.io devs
now that it's open sourced, am sure it'll take like a second for someone to release the deb package
[1] - `ln -s $(which nodejs) ~/bin/node`
(or make the symlink yourself.)
https://aur.archlinux.org/packages/atom-editor-git
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.
apm install resize-panes
Obviously you don't use emacs.
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.
Separating it out has a lot of advantages, especially by not putting in much opinion by default.
From the FAQ: "At the moment Atom only runs on OS X (10.8 or later). Windows and Linux releases are on the roadmap."
Which version of Ubuntu did you use ? Howz the experience ?
sudo ln -s /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.0
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 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.
Good news! There's a package for that: https://atom.io/packages/minimap
I imagine that eventually there's not going to be much difference feature wise between ST and atom.
This then leaves the key differentiators as price and support. Atom wins the first, and if the community grows with it then it'll soon win the second.
edit. Oh yes, the speed thing. ST wins that.
It works, hasn't crashed.
Still keeping emacs around for org-mode.
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.
Anyone polite asks, or doesn't do it at all.
That's analytics.
If you care about that sort of situational awareness, there are tools like Little Snitch that make it easier.
(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.)
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. :)
Text editors are dime a dozen and in that space, you are competing with much more than tools that are geared just toward developers.
Maybe the slightly-snarky lesson here is "developers will pay decent money for a text editor... on OSX".
Developers will pay decent money for any editor that helps them create better code (and thus more money). :-P
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.
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 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.
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.
It looks and works the same on all platforms, OSX, Windows, Linux.
So maybe there is something in that the OSX crowd will pay for tools.
That said, I find it far easier to get up and running with a myriad of free software on OSX than I ever did on Windows (much love to homebrew)
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.
I wonder if Emacs will eventually compete, though, both UI-wise and for cleaner plug-ins.
[1]: In my humble opinion
[2]: and I do, actually
What's your use case? I'm curious.
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.
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)
Does that mean NeoVim will support Lua for scripting alongside VimL?
> 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.
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.
The first time I've heard about Atom was here: https://medium.com/p/433852f4b4d1
+1, an about page wouldn't go amiss either. I still don't know what it is.
[edit] Wow, downvoted. I just want to know what it is by visiting the website quickly. It's not a lot to ask.
https://atom.io/
I just can't imagine a behemoth like Github not injecting itself into Atom for the better.
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.
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.
Of course there is Google, Amazon, Red Hat, SUSE, even IBM uses a lot of GPL software...
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?
So unless you make the effort to contribute back, they will have some issues to pay the rent.
A copyleft license would prevent someone else, who does not hold copyright on Atom, from doing that.
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.
http://en.wikipedia.org/wiki/Open_core
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.
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.
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.
It would preclude using so much code in extensions, for no particularly good reason.
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.
EDIT: I fudge fingered this. I meant copy left license. MIT is a free software license.
“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
There was a HN discussion about this here: https://news.ycombinator.com/item?id=7310017
I buy Orson Scott Card books, for example.
Some people don't partition the reputations of corporate 'entities' into separate walks of life.
"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.
[0]http://opensource.org/osdhttp://opensource.org/osd
[1] http://en.m.wikipedia.org/wiki/Shared_sourcehttp://en.m.wiki...
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.
That's under-promise/over-deliver in action my friend :)
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.
You need to add your public key to your github account.
https://github.com/settings/ssh
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.
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 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.
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.
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.
(1) I've written lot's of elisp code, for example a norton commander clone called evening commander (https://github.com/pgundlach/evening-commander)
In the end, for most of these products, open sourcing is usually just the last step before the product dies.
1) https://github.com/blog/69-what-os-do-you-use
-Posted From Linux