Hacker News Reader

Comment by pachydermic | Hacker News Reader

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.

Good on you, Atom.io devs

View on HN

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.

Who's actually using Atom as their main editor?

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.

Not main, but I stopped using ST for it.

I won't even give it a chance over ST until I can resize panes, unfortunately. How that isn't a feature is beyond me.

there is a package for that: https://github.com/santip/resize-panes

apm install resize-panes

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.

> But how can putting this functionality into an extension package be considered a reasonable design choice?

Obviously you don't use emacs.

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.

I'd like to try it but I don't own a Mac.

From the FAQ: "At the moment Atom only runs on OS X (10.8 or later). Windows and Linux releases are on the roadmap."

The atom repo https://github.com/atom/atom has installation instructions for Linux and Windows. Just installing it on Ubuntu to give it a try.

Recommended Ubuntu LTS 12.04 is too old, now that next LTS, 14.04 is already out.

Which version of Ubuntu did you use ? Howz the experience ?

I use 14.04 and ran into this issue https://github.com/atom/atom/issues/1946 like several others. Adding the following symlink fixed it:

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.

It wasn't too painful to get running on Windows. Main pain points where making sure I had the correct versions of all of the dependencies installed.

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.

> Visuals - The open file code overview on the RHS is a must have for me.

Good news! There's a package for that: https://atom.io/packages/minimap

Thanks!

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.

Been using it as my main editor for two months now. Only real complaint is that it slows down over the day and needs restarting.

Had a mode extreme version of that - if I kept it open the whole day I had to restart my laptop.

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.

I've been using for two months as my main editor.

It works, hasn't crashed.

Still keeping emacs around for org-mode.

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

I use it as my daily editor and have been pretty happy so far.

Would you mind sharing why you the team didn't want to go down the partially open, paid app route?

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.

The idea of analytics in a code editor is just depressing.

I think nowadays you'll find analytics in just about anything consumer facing.

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.

Anyone polite asks, or doesn't do it at all.

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

That's analytics.

As I said, anyone polite asks, and many don't do it at all.

Contacting a server IS asking. You can block the connection if you like.

How is contacting a server, unnecessarily and without user's informed consent or even knowledge, considered asking?

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.

That's the dumbest definition of "user consent" I've ever heard.

Well, it means every user to ever visit my website has consented to having my virus' on their PC, right?

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

> I wonder why it wasn't this way from the get-go

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

Developers will pay decent money for a "code" editor (an IDE), not a "text" editor.

Text editors are dime a dozen and in that space, you are competing with much more than tools that are geared just toward developers.

It doesn't have to be a full IDE. Sublime Text and Textmate before it have both been very successful while charging a respectable fee.

Maybe the slightly-snarky lesson here is "developers will pay decent money for a text editor... on OSX".

I've paid for Sublime and I run mostly Arch Linux systems.

Developers will pay decent money for any editor that helps them create better code (and thus more money). :-P

Any particular reason you chose sublime over Vim?

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.

TM is now open source and a lot of ST users are stuck at V2. I dont think there is a lot of room for another product.

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 thought that was one of the big plus points for ST.

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)

Code is text last I checked. I see what you're getting at, but "text editor" encompasses that already. For everyone I talk to anyway.

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.

What rough edges?

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.

[1]: In my humble opinion

[2]: and I do, actually

on [2] assuming gvim, try --remote-silent, vim buffers are much easier to work with than whatever app switching your os provides.

> I can open a hundred instances

What's your use case? I'm curious.

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)

> VimL -> Lua(JIT) translator is already quite advanced

Does that mean NeoVim will support Lua for scripting alongside VimL?

Yes.

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.

Yeah. I went through that with TextMate. It was worth what I got out of it though in the long run.

It can be both commercial and open source, they are not mutually exclusive.

The instructions for building the linux version are in the readme

Interesting, thanks for the heads up. Last I heard it was OSX only. I may try this when I get home.

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

In the meantime, can't you just symlink or alias that problem away?

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

[1] - `ln -s $(which nodejs) ~/bin/node`

Surely you mean /usr/bin/node instead of ~/bin/node...?

Why? If you have ~/bin in your path, wouldn't not cluttering the global bin be preferable?

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.

$ apt-get install nodejs-legacy

(or make the symlink yourself.)

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

The Arch AUR has a PKGBUILD up.

https://aur.archlinux.org/packages/atom-editor-git

You emphasize a lot. But all it takes is creating a copy of nodejs from /usr/bin and putting it back with the name node. Not much tweaking at all...

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.

You can build the Linux version right now. Same for Windows.

Reply on news.ycombinator.com