Live data from Hacker News

Atom

atom.io

281–290 of 662 posts

Re: Atom

#282
Is it just me or do most of the new IDEs tend to focus around front-end technology?

Would love to see some innovation on the Ruby editor front.

Re: Atom

#283

I was all ready to be skeptical and everything... but this could actually be amazing. I currently use Chocolat for code editing, which is beautifully elegant and I love it, but there are 25 little tiny things that I really wish I could fix. I file issues, but the developers rightly have their own priorities. It's closed-source, but even if it were open source, I'm not about to learn how to use XCode and Objective C a…

I'm with you. I'm an Emacs user, which ostensibly has a similar design philosophy (open source, with powerful extensibility from a full-blown programming language), but Emacs Lisp has a lot of baggage and is nowhere near as widely used as JavaScript. I also find the Emacs community disjointed and hard to navigate and participate in. Ultimately, assuming that the underlying design decisions of Atom are reasonable, its success will depend on the community that develops (double meaning intended) around it. It could be great.

Re: Atom

#284

Apparently this was almost 6 years in the making. https://twitter.com/defunkt/status/438791340222971904

I wonder how long Atom has been usable. Chris stopped updating his Emacs packages in 2012.[1][2] [1] https://github.com/defunkt/coffee-mode/commits/master?page=7 [2] https://github.com/defunkt/textmate.el/commits/master

4 months ago...

https://github.com/defunkt/gist.el

Re: Atom

#285

Earlier quoted context omitted.

A good VIM keybinding plugin is a must for me as well. The one available for LightTable, for instance, simply wasn't sufficient IMO. I can't specifically remember what it lacked, but it was enough to throw me off. Vintage mode in ST2/3 isn't perfect, but it's pretty solid. Atom looks interesting. I really look forward to trying it out.

Agreed. Nothing beats evil-mode in Emacs, as far as I'm concerned. That's a model for other vim emulation layers to follow IMO.

Don't hear as many folks talking about emacs in evil mode. I tried that out for a bit, and I'm not really sure why I didn't stick with it. I used it a few months. I always liked the modal nature of vim and the operator/motion sequences, but I'm a fan of lisp/emacs and remember enjoying how emacs was put together more, from a modification standpoint (I don't remember any of it now)

I'll have to try that out again

Re: Atom

#288
post #244

I've just had play around with the beta. It looks like it's using a version of CodeMirror 4 (as it has multiple ranges). Fairly fast but it doesn't match Sublime Text just yet Initial impressions: it's early days but this thing is just oozing for customisation. The fact it's written in JS means writing packages is pretty simple compared to Python for ST; we're going to see TONNES of addons for it. I can already think…

> Initial impressions: it's early days but this thing is just oozing for customisation. The fact it's written in JS means writing packages is pretty simple compared to Python for ST; we're going to see TONNES of addons for it. I can already think of 2-3 I'd like to build. This isn't why it's going to be popular for plugin development though. Sublime plugins are Python, which isn't that hard to learn. Atom's plugins a…

> This isn't why it's going to be popular for plugin development though. Sublime plugins are Python, which isn't that hard to learn.

Agreed, but Javascript has many more developers who know JS over Python. From my initial glance at the docs the learning curve for package development isn't too steep either.

Re: Atom

#289
post #274

A common thread or line of argument that I find when reading about new editors is their out-of-the-box ease of use compared to Emacs and Vim. For example, a quote from the Atom blog: >Sublime and TextMate offer convenience but only limited extensibility. On the other end of the spectrum, Emacs and Vim offer extreme flexibility, but they aren't very approachable and can only be customized with special-purpose scriptin…

There is no reason why "editing plain text" should be anything other than immediately intuitive. Advanced, time-saving features, like multi-cursors or regexp-based find-and-replace, can and should be progressively revealed through normal use of the software. This ludditic reverence for user-hostile text editors is one of the more perplexing and frustrating things about our industry.

Editing plain text is in fact very easy. Structured text requires a little more logic, however. Ultimately, you could use emacs in the exact way one would use notepad++ and be none the wiser to the rich customizations under the hood. If thats your bag of tea, drink it.

Re: Atom

#290
I'm really sad to see that they totally blew it.

The performance of a webapp with the accessibility of a desktop app. Not to mention that it's closed source. This is a tremendous step backwards.

Looking at the implementation of the open sourced packages is discouraging as well. It looks like they are using a Backbone inspired jQuery infested nightmare of clientside MVC.

Maybe my bitterness comes from the fact that I've already been down that road and it leads to a bad place.

Here's an editor that has deep Github integration, runs in the browser, and self hosts: http://www.danielx.net/editor

Maybe I just live too far in the future.

Post reply on HN