Hacker News new | past | comments | ask | show | jobs | submit login
Atom (atom.io)
1475 points by hswolff on Feb 26, 2014 | hide | past | favorite | 642 comments

From "The Zen of Programming":


Hearing a disturbance, the master programmer went into the novice's cubicle.

"Curse these personal computers!" cried the novice in anger, "To make them do anything I must use three or even four editing programs. Sometimes I get so confused that I erase entire files. This is truly intolerable!"

The master programmer stared at the novice. "And what would you do to remedy this state of affairs?" he asked.

The novice thought for a moment. "I will design a new editing program," he said, "a program that will replace all these others."

Suddenly the master struck the novice on the side of his head. It was not a heavy blow, but the novice was nonetheless surprised. "What did you do that for?" exclaimed the novice.

"I have no wish to learn another editing program," said the master.

And suddenly the novice was enlightened.

> Sometimes I get so confused that I erase entire files

OT, but just this week my wife did something that really got me thinking about how far computers haven't come in terms of usability.

I heard her say "O crap" from behind her macbook, and out of habit I came to assist.

For some reason unknown to both of us, she had pasted the text of an email into a document called "thesis.docx", and then saved it.

The text was completely unrelated to "thesis.docx", which of course was not backed up.

Now, I love my wife deeply. And she is no fool. On the contrary, she is a graduate student.

Moreover, I completely understand how something like this can happen. We have two small children, and it was the end of the day. It is just too much to expect of the human mind that one should not say something one doesn't mean.

I felt guilty on behalf of my profession that this was the best we had to offer. Microsoft word on a macbook, and your penultimate version of a file is not backed up. It truly is intolerable.

So, while I have had some of my greatest highs using emacs macros, I somehow feel that the brilliant tooling made by developers for developers never quite percolates into userland.

Sometimes I am boiling a stew, and while I am preparing another dish on the side, for some unknown reason I put the raw eggs on the stew instead of the fry pan.

Pans have been there for centuries, and there is nothing preventing me from throwing stuff in the wrong place, nor undo the eggs in the stew. It's so intolerable, and I feel so ashamed and guilty on behalf of all the pan makers.

Not. We are in a field where we can prevent a lot more stuff to happen than in the real world (and the real world is soooo broken...). We should try our best to make the state of usability and fool-proofness advance as much as we can, and surely there must already be something that would help your wife's case. But we should also be more realistic when voicing expectations.

No, no, no. This is why reasoning by analogy can lead you astray. We have enough control over the world of software that the problem described above should not exist. This control does not exist in the real world, but it does in software.

Do we have enough control over software to make it impossible for someone to delete something and make it unrecoverable when they will later realize they should not have done so?

Not impossible, no. But we absolutely have enough control over software to make it highly improbable for someone to accidentally delete something important and make it unrecoverable.

I don't think he's voicing an expectation so much as lamenting a pervasive and realistically solvable, or at the very least approachable problem.

His problem (or his wife's) is solvable, even right now. She could use time machine, dropbox works as well, using a versionning system would also work, she could switch to an editor that supports infinte undos, dozens of other solutions exist.

But all these require preparation, settings and some care. It could get better, even 'magical', but it would be an achievement that should not be taken for granted.

Btw we could make a pan for stew that checks if you are adding eggs to it, but no one would want the tradeoffs IMO.

> "thesis.docx", which of course was not backed up.

Something I find hard to belive from a woman whose husband is reading hacker news.

'thesis' and 'not backed up' are forbidden to appear in the same sentense by "the Universe(tm)". This law is enforced by _always_ deleting the contents of 'thesis'.

> Microsoft word on a macbook, and your penultimate version of a file is not backed up.

From that sentence, I interpreted it as the latest version of the thesis was not backed up, and that she may have lost several days' work.

Vim persistent undo solves this problem:


...I'm sure Word will catch up eventually.

Emacs autobackups (which are on by default) would have also helped here.

Exactly, and the fact that previous / older editors (and operating systems) have solved this "problem" supports the Zen Master parable.

Not in this case. If you accidentally `:w! thesis.txt`, persistent undo isn't going to help you.

Clipboard manager. Set to record X selections too. That does it for me. Every bit of text I select is copied to clipboard, just below the value currently held there. In this case I'd have the full content of the docx file as a second item in my clipboard manager list with an email as a first one. I set the size of the clipboard items list to 500, just in case.

I couldn't live without some kind of clipboard manager. It was Ditto on Windows and klipper now on Linux. Dunno about Mac OS, but I bet there is something with similar functionality. It adds another layer of protection to Ctrl-Z everywhere and undo-tree-mode in Emacs. As a programmer I deal with text all the time and I need to be able to recover as much as possible if I make a mistake and this (clipboard manager + undo-tree + version control + normal undo) is the most robust system I could find.

Re: OS X clipboard/pasteboard manager.

I've used ClipMenu [1] for years after using Jumpcut [2] as far back as 2003.

[1: http://www.clipmenu.com ] [2: http://jumpcut.sourceforge.net ]

I actually have some scripts which take textual snapshots of all my open non-idle terminal windows every 10 seconds.

This has saved my butt a number of times.

For this purpose I set very large history in tmux and I almost never use terminal outside tmux anyway. The panes and windows in my tmux are very long-lived, but when I decide to close one I need to go through it's history and manually extract interesting/important bits. It's annoying and automating this would be really nice though.

Seems to me that a clipboard manager as a solution is indicative of how this type of a problem comes up in the first place...

Works for me. Across multiple vim sessions. Unless, you mean a new file thesis.txt, in which case the old file is untouched.

Time Machine is perhaps the most elegant, least intrusive backup software ever. And it's free with OS X. I can't recommend it highly enough, especially for someone in your wife's position.

To belabor the obvious: Time Machine saves old versions for you even if you don't have a separate backup disk, subject to available disk space.

I literally just discovered this when using a terminal and navigating to /Volumes and seeing the /Volumes/MobileBackup.

Hopefully I never have to use it, but pretty cool none the less.

VMS file versions solved that problem in the late 70ies. We are not learning anything from out history as a profession.

I'm a loyal unix guy but as a millenial without much actual hands-on experience with VMS I always love to hear anecdotes like that :) The first time I read about it was in Clifford Stoll's Cuckoo's Egg where it seemed as if there was constant competition between UNIX/VMS folks over which was the more sophisticated/elegant operating system - mostly good hearted competition of a more civilized age of course ;) I vividly remember the one encounter I had with it's weird shell where I had to re-configure an application running on an Alpha machine which had a consecutive uptime of something like 12 years...

One of humanity's biggest enemies to progress are "Not invented here" and the cult of youth. It's often better to start with a blank slate ("being ignorant") because amongst other things like simply having a different perspective (worth 100 IQ points ~Alan Key) it helps with actually starting to build something. Eventually though we should still be aware of what we as a collective have learned already.

To be fair I think Github folks should know their history so this project might be one of the exceptions - looking forward to it! <3

How do you differentiate "the cult of youth" from "it is better to start from a blank slate"?

Side note: Neither of the two issues you mentioned are "one of humanity's biggest enemies to progress."

I guess it boils down to respect - for both sides, young and old. Thanks for the compiler error ;)

being ignorant

"Ignorance is Strength" (1984)

Only in the same sense that public-key cryptography in the 1990s solved the problem of secure electronic communication between two parties. Creating the technology is on big hurdle; getting enough people to adopt it so that it's actually useful is sometimes a bigger hurdle.

I wouldn't say "solved", as it's still pretty easy to accidentally overwrite old versions, but it was a step in the right direction. VMS is full of good ideas that never went anywhere.

Netware too, but that was in the eighties.

I like DragonflyBSD. It versions everything by default. (But no one uses DragonflyBSD of course.)

+1 for VMS.... so good, but so proprietary & doomed to extinction... so unfortunate.

Amen brother. Tragic that we haven't even good back to the 80s

Btrfs and ZFS would have helped, too.

It's not her fault. One should be able to undo file system changes. Bell Labs solved this long ago by storing every file version forever http://en.wikipedia.org/wiki/Fossil_(file_system) Storage is cheap

No, storage is not cheap! It may be if you're only counting files like "thesis.docx" that involves directly the user, but in reality we have a lot of programs that do automatic file operations and that would be nothing but storage trashing not to count the performance handicap.

Sure I'm talking about user generated data. Other bits are just cache or temp, easy to recreate.

"Microsoft word on a macbook, and your penultimate version of a file is not backed up."

Your comments makes me think that neither you nor your wife knew about tracking changes in office documents: http://office.microsoft.com/en-us/word-help/track-changes-wh...

But then considering that the unfortunate loss of data happened after an already lengthy sequence of manual actions, I wouldn't be surprised if the "o crap" would come after a longer sequence that involves disabling whatever should have been prevented the unpleasant events. I'm sorry for the loss, but I don't find my profession responsible more than I would find a car designer/engineer responsible for a car accident caused by driver's deficient attention.

Although really software should be idiot friendly and default to not letting you delete stuff by accident. As an aside I've managed to delete my code more than once in a similar manner in PyScripter which makes me feel rather silly but is quite easily done.

As mentioned time machine is a great feature, but doesn't OS X auto save files you're working on with its versions? You might want to double check that it hasn't got past versions saved.

Except that Microsoft Mac software neither follows OS X conventions (e.g. putting Office system files in the user's doc dir) nor implements many of the important features (e.g. leveraging the automatic file versioning introduced three years ago in OS X Lion).

The current version of Office Mac predates Lion, which is probably why it doesn't use Lion features.

The file revision history is - to the best of my knowledge - an OS X API that applications have to use (opt in). I don't think it comes "for free" with an OS upgrade, unless you mean Time Machine.

How exactly can he check it? As a user of another OS, I'm asking to learn how this feature actually works.

It's easy. Right there in the File menu near the Save command is Revert To, which leads to a submenu with Previous Save and Browse All Versions... options. The latter uses the slick Time Machine UI (http://support.apple.com/kb/ht4753).

Except, per my other comment, Microsoft doesn't bother writing Mac software that works like Mac software. It's kind of like running Java desktop software (actually worse)... neither native feel nor integrated with the OS like other Mac apps.

As you say "Microsoft doesn't bother writing" and his girlfriend uses MS Word on OS X if I understood. Can she then use that feature to recover her work after she had done the "Save" from the MS Word or not?

No, she's probably not going to be able to recover her lost work. What OP and others are trying to point out is that OS X has support for saving revisions to documents if application developers (like Microsoft) would just take advantage of it.

What did you do? Was her whole thesis gone??

I would like to recommend http://crashplan.com. It is set and forget online backup that keeps versions!

Inexpensive and truly unlimited storage. Windows, OSX, and Linux too!

It's a daily backup, so no it doesn't keep versions. Nice try crashplan employee...

I believe the default crashplan setting is 15-minutely. It saved me and my from the described situation many times.

You'd need something like ElephantFS whose presmise was precisely this. Modern file systems still don't protect user's data the way they should.


Why even give users control of the data? No, that should rest squarely with the file system and ait should never delete things unless it is running out of space.

Even worse, Mac apps are trending towars the "save as you go" model of Google Docs, which has the one advantage of you don't lose your work if an app crashes but if you started editing the wrong document, or make some changes and then change your mind and want to revert back to the last saved version you are tearing your hair out. The latter happens to me much more often.

Assuming the app has implemented the new saving model correctly, it will also keep a history of every version:

File > Revert To > Browse all versions

Indeed - the OS X model fixes (to some extent) the problem in question, not exacerbates it.

As evident from the comments above, one of OS X's biggest weak points is feature discoverability.

I love how OS X stays out of your way, but most regular users never get to take advantage of greater complexity. You have to be in the mindset of one of 'us' (reading every update to Apple's PR) to get a handle on everything OS X can do.

Hardly, it was well advertised when Lion came out.

Exactly. If you got your first Mac post 10.7 (and you're the average user) you've got no idea you have such a feature.

Maybe you find it one day trolling through the menubar. Maybe you don't.

My 6-year old version of Word 2008 has an option to always make a backup of the previous version when saving, which (unfortunately in this case) is off by default.

I'm using dropbox for document backups. Just edit your files inside your dropbox folder and your documents will be versioned.

Same here. As well as Time Machine. Just in case Dropbox ever breaks.

When I started working on my thesis, I immediately set up my entire document directory for it to be in Dropbox. At the time I paid extra for versioning but now I think it'd built into even the basic model. This also saved my friend when she was in writeup and someone stole her Macbook.

Not sure if this will help regarding change tracking in MS Word...


Why wasn't she using versions?


> It is just too much to expect of the human mind that one should not say something one doesn't mean.

Careful, that is quite a slippery slope...

Cmd z?

She probably had closed the file before the "o crap". Undo does no good there.

Then this really isn't a usability issue, if you replace the entire contents of a document with the clipboard, then click or shortcut to save, then click or shortcut to quit the application, that's really a human issue. It's too many steps to be labelled as a usability problem.

⌘-Z should have been adequate.

> "that's really a human issue ... ⌘-Z should have been adequate."

I hope you don't work in usability.

I've made exactly the mistake described, several times. When making small changes to a bunch of files, it's common to go through the whole open-edit-save-close sequence in a few seconds, and if you've got a few things open and someone's talking to you, it's easy to fuck up.

Whether it's a human issue or a software issue it could still be solved by better software.

> In other words, always blame the software.

> I get it, but the convenience of things like ZFS and Time Machine have a cost. It takes time to implement such things and they take resources. And even then a failure is possible.

You need to weigh the development cost of a feature against the cost to the user of not having it times the number of users. It is usually cheaper to make the software do the tricky stuff than to make your users do it.

In other words, always blame the software.

I get it, but the convenience of things like ZFS and Time Machine have a cost. It takes time to implement such things and they take resources. And even then a failure is possible.

E.g. you decide to do some kind of Garbage Collect on a HD, because you lack disk space and you don't want to buy a disk, but you forgot to backup a file you deleted a month ago.

I'd break it into two categories. There's software that expects you to be an expert.

Then there's software that's designed to allow lay-people to get stuff done with the promise that it will hide the nasty things of the world from them.

Microsoft Word really is the perfect example of this. The main use-case it's built around is being a lovely place for a new user to write and print a small document. It captures users from this simple use-case, and then tries to upsell them to large document and multi-user scenarios with madness like mail-merge wizards and sharepoint.

The promise of Microsoft Word is to bring functionality to users while shielding them from the nasty realities of the world. It's reasonable to be vicious about it when it fails to protect the user from themselves.

If the computer remembered every modification of every document, then users would be protected from incidents like this.

What about when they accidently release private information because the information was at some point in the software. I'd rather a single backup system like time machine than every application reinventing the wheel with all the bugs that entails.

Yes, but in that case we would be talking about yet another privacy issue here.

That's why it should be the file system storing backups, not the document itself.

One should also consider a logarithmic decrease in backups: while I'm writing, a backup of the state a few seconds ago is useful, but I don't need every second from weeks ago. Say the system keeps a backup of every few seconds for the last few minutes, every few minutes for the last few hours, every few hours for the last few days, every few days for the last few weeks, every few weeks for the last few months, every few months for the last few years--the odds are then pretty good that I'd be able to revert to a version I find useful, but not requiring an awful lot of versions.

Back of the envelope: 5 versions/minute for 5 minutes = 25 versions; 4 versions/hour for 8 hours = 24 versions; 3 versions/day for seven days = 21 versions; 4 versions/week for four weeks = 16 versions; 1 version/month for 4 years = 48 versions, so a grand total of 134 previous versions of a document, which really isn't that much space, particularly assuming efficient differencing algorithms.


Still a privacy issue.

I wrote software to handle this a long time ago never got off the ground www.foldertrack.com

Doesn't Word store old data in the .docx, for things like revision diffs and to make saving quicker? Unless the filesize is really small, there might be a way to extract the previous data... Maybe that was only in the old .doc format, though.

ummm.. if you didn't do it then, i suppose it's already too late, but ctrl-z (i guess that's option-z on a mac?)

"Now, I love my wife deeply. And she is no fool. On the contrary, she is a graduate student."

No offense, to you or your wife, but this statement is hilarious for several reasons!

What is this, 1999? You should have your whole family using Google Docs. It's backed up as you go, and you can view all previous versions using File->View Revision History.

Could that also be interpreted as:


Hearing a disturbance, the master programmer went into the novice's cubicle.

"Curse these search engines!" cried the novice in anger, "To find anything I must scroll through three or even four pages of results.

Sometimes I get so confused that I just give up. This is truly intolerable!"

The master programmer stared at the novice. "And what would you do to remedy this state of affairs?" he asked.

The novice thought for a moment. "I will design a new search engine," he said, "a search engine that will replace all these others."

Suddenly the master struck the novice on the side of his head. It was not a heavy blow, but the novice was nonetheless surprised.

"What did you do that for?" exclaimed the novice.

"I have no wish learn another search engine," said the master.

The novice packed his bags, left and went on to create Google, which gives him exactly the results he's looking for.

While his former master was left sifting through multiple pages of results on (insert other search engine here).

One day the master stumbled upon Google and the master was enlightened.

learning the facets, quirks and customisations of a text editor can't really be likened to the 'pick-up and go' model like a search engine.

Google UI is basically the same as the rest. Can't compare learning a professional tool to that of lay infotainment service.

I think the first assertion is simply untrue, and without it the rest is nonsense. You don't need to learn how to use multiple editors to do anything.

I suppose there are some languages/environments that are somewhat tied to certain editors (java and eclipse, C# and visual studio, objective-C and xcode), but that's not what is proposed here. It's a general purpose programmer's editor that anyone can use for anything. Are you really upset that it's being written? Why do you think you'll have to learn it?

I think it's also worth mentioning that Atom, like Sublime, looks straight-forward out of the box. You don't need to learn much to be productive. It doesn't have the learning curve of vim/emacs, but it's more powerful than Sublime/Notepad++/Gedit etc.

Also, I don't think anyone needs more than one general purpose text editor like vim or Sublime or Notepad++, and possibly a full-featured IDE like IntelliJ or Visual Studio. If there's a counter-argument, I'd like to read it.

tbh with you i've used both omnisharp and eclim with vim.

you get full IDE features as well as refactoring inside of vim. for most things you can use vim as a full featured IDE these days.

well for refactoring you might have a few issues on, say, c++ and objective-c

[] http://eclim.org

[] https://github.com/nosami/Omnisharp

The solution for n competing standards is n + 1 competing standards.[0]

[0] https://xkcd.com/927/

If the master thinks that the human race has reached the absolute pinnacle of human/machine interfacing for text editing after just a few short decades of trying then he needs to go away and have a little sit down and a think about where he went wrong in life.

Nah man, you're not enlightened. He's not saying don't build a new editor, just that you had better think long and hard before you decide to foist another learning curve on the world, and act like you're doing it a favor.

Also, https://xkcd.com/927/

Nobody foists a text editor on anybody, they live or die on their merits as a text editor. And besides, where would the world be know without people trying to make things better? The master's wisdom is weak in this case! I strike him on the side of his head! Slap!

It's a fair point, but by this rationale no new DBs or PLs should be made. Most of these die off or become niche, the ones that really become fundamental are few and far between. This idea that we have to drop everything and go "learn" this new thing is bogus. Folks in tech often seem to buy into the hype of some new technology all too easily, riding the wave of excitement. So their shouldn't be any concerns, of "yet another editor”.

BTW, I'm not saying this won't be successful! It looks interesting and I am excited, GitHub does great work, but you keep it in perspective.

somewhate relevent: https://xkcd.com/927/

I love learning new things! If it's better then I am more than happy to learn it, otherwise we'd all still be using EDT...

This "master programmer" need to stop abusing his novices, stop resting on his laurels and get back to some learning.

It's interesting that people keep using the word "better" when it comes to new editors/languages/frameworks/etc, yet as an industry we have very little evidence to proof it.

I've been doing this programming thing since the 80's, and the only thing I've seen that has really made software development better have been better practices.

Maybe we should first review our definition of "better" before we label something with it. Too often it's used as a synonym for "ooh, shiny!".

Having said that, Atom looks nice and shiny.

Nonsense, you didn't even have CVS in the 80's.

Maybe not, but I'd take pass-the-floppy over AccuRev or Perforce any day.

Yeah, git and its kin are really nice, but the expensive version control systems I've been required to use in enterprise settings are awful. So awful that many people actually just email source files back and forth so they don't have to deal with it.

So, version control has made things better in some areas. But enterprise version control feels more like a step back to me. AccuRev has literally stolen entire mornings from me because what should have been a simple two-minute check-in took almost 3 hours to complete and was interactive! Yay!

That's a shame. All the enterprise places I've worked so far have used Subversion (whether officially or not).

Hence the name.

we all have far less time than it would require to learn all of the interesting things. Once you get good with an editor your time is much better spent learning a new data structure, algorithm, language paradigm, etc than learning a new editor.

Thats maybe true for the vims and emacses of the world, but these new editors come with a fancy pants thing called a GUI. These GUI thingys adhere to certain standards and customs that are set by the OS. I do some web development work from time to time and therefore I have multiple browsers installed on my machine. I can switch between them without having to dig through a manual! I have to learn hardly anything!

I don't know how long Emacs has had a GUI, but it's at least 20 years.

I don't remember what the graphical capabilities of GNU Emacs are like, as I only use the command line version, but XEmacs at least also has extensive support for bitmaps graphics in buffers that far exceeds most of these "new editors".

GNU emacs can show bitmap images. I'm on the latest version 24.x and just tried it out, so I'm not sure when it was added.

It's hard to track down when it was introduced, but it looks like there was at least some bitmap support as far back as Emacs 18, which predates the XEmacs split and indicates that at least basic support may date back to 1986.

You aren't using your editor in the sense that most people here are talking about if you don't have to learn anything.

As others have pointed out, Emacs has a GUI. But the fact that you didn't know this might suggest that the GUI part of Emacs isn't integrally linked to the killer features of Emacs.

Learning tools like Emacs is for many a matter of productivity. If you want productivity, you want to streamline your most commonly used actions. Streamlining things in an editor will probably mean to use keybindings, since you're using the keyboard to input text anyway. Then you have to memorize the keybindings (or: your fingers have to), and you have to practice using it to the point that it actually becomes more productive than whatever previous routine you had - you have to fight your old habits.

Building these habits is what takes time. The fact that Emacs has a GUI helps with feedback and discoverability, not that much with building habits. When you have finally built these habits, only then can you know if you are more productive. If you aren't you might have to unlearn a lot of your habits (for example by learning modal text editing).

- Written in my Emacs

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 and figure out how to compile and whatnot.

But if Atom is ultimately just a big collection of straight-up node.js files, and anyone can go in at any time to change a line here or there -- and it's in JavaScript, so it couldn't be easier for programmers in general -- and there's no compilation step or anything -- then it's almost a fundamental paradigm shift for what desktop software could be.

It already makes me dream of a word processor I could hack like that, or a music player. Just by opening up a text editor. It's an inspiring thought.

> and there's no compilation step or anything -- then it's almost a fundamental paradigm shift for what desktop software could be. > It already makes me dream of a word processor I could hack like that, or a music player. Just by opening up a text editor. It's an inspiring thought.

Not to rain on your parade or anything, but you can already do this with Emacs, not to mention that Emacs is free, open source software. Atom is not only not open source but their readme says it won't even be free after the beta.

Emacs has been around for almost 40 years, and because it's FOSS it will be around for at least another 40. Editors like Atom come and go.

Oh what, it's not open source? The little interest I had in this just evaporated. I would definitely be interested in something like Emacs built on modern technologies, but Emacs is already there and quite good. I feel like something like this could be neat, just because far more people know HTML/JS than Elisp, but if it's not open source that kills my enthusiasm for the project.

Checkout lighttable.el


Nice. I was able to read and understand the whole implementation on my phone.

Of course, thanks to Apple, I can't load and eval it, but I will take it for a spin when I get to a machine. :)

Brackets (http://brackets.io/) is another option - it's MIT-licensed, and also written in JavaScript.

True, but it's a question of accessibility.

Far more people can program in JavaScript than Lisp, and far more people use GUI desktop software that follows traditional GUI user-interface paradigms, than do things inside their terminal. (Edit: or terminal-style buffers/frames.)

So that's why my statement was limited to what "desktop software" could be. :) I mean, I use LibreOffice, which is FOSS, but I am never going to touch its code in a million years. The cost-to-benefit ratio is too high. But Atom makes doing that sound almost trivial. That's the paradigm shift.

> That's the paradigm shift.

You can make desktop apps in Python, Ruby, Tcl, hell even PHP for a long time now. No compilation needed.

Whether this works effectively or not comes rests almost entirely on how good their architecture is. "Hackable" doesn't mean anything if the codebase is a coupled mess. Given GH's pedigree, I don't expect that this is the case; which means there will be some ramp-up time learning the various subsystems.

Desktop apps aren't things that you can cram into this week's hipster JS framework.

Redcar is a TextMate compatible editor in Ruby (JRuby).


But like all editors, they have to have some clear advantages and a community, or it's not a viable option.

Yes, Redcar is pretty cool! This is an inspiring talk on how to hack on it - even though I'm still mostly using vim/sublime it was pretty eye opening to me, rubies all the way down:

Crafting iOS Dev Tools in Redcar - Delisa Mason (#inspect 2013)


I don't follow. These hipster JS frameworks have to work well on phones and various inconsistent browsers. Targeting the desktop and one JS environment seems feasible.

Emacs is GUI desktop software. Few people use it in a terminal.

Also, people didn't born knowing Javascript. They learnt it. And one could argue that Lisp is just as easy to learn, if not easier.

I'm sure the emacs GUI runs great on your macbook, but for people who live on remove linux servers day in and day out, trust me they are using emacs in the terminal.

That or they're using tramp to ssh in to the remote machine and edit that way.

Actually it doesn't run great. It's so clunky you might as well just run it in the terminal.

I mostly agree with that although I think it's also kind of irrelevant in a practical sense because many programmers already have to know javascript for their work so you get a lot more people who can contribute right away.

Aside from that -- lisp or javascript as the extension language, I'd love to see a brand-new extensible editor like emacs just to have a shot at changing terminology and some of the APIs. Emacs terminology is a little off-putting because it was invented before the GUIs were widely adopted so it doesn't map that well. I also find some of the APIs a bit weird, but that could just be me.

It's true that a lot of people work with Javascript, but honestly I wouldn't say that they can contribute to anything right away. A lot of these people don't know more than

In fact, I would wager that there are more potential contributors to Emacs than there are to Atom.

But if someone just wants to customize their text editor, $('#element').hide();, or something not orders of magnitude more complex, would actually be useful.

That's totally exaggerating. Anyone who is that green to code is probably not even thinking extending their editor yet, and any working programmer has picked up more than enough JS in their to be able to write and understand far more than that line.

Plus, Emacs is a ghost town anyway. You're going to run into the problem that there are not bodies willing to use the editor, let alone extend it.

Yeah, it's definitely true that a large percentage of people who "know" javascript have about that much knowledge. But still, if you look at absolute numbers of people who can make a function and write a for loop in JS, it's still going to dwarf the number of people who can loop and write a defun in elisp.

What'd be cool is an editor that had LLVM IR as a low-level extension language. At runtime, it'd JIT your plugin, and go.

Have you seen Light Table? Go check it out!

Good point!

Most emacs users I know alias emacs to emacs-nw, or install emacs-nox.

Myself included (:

Most emacs users I know don't. Myself included.

I have it aliased but for some reason I still add -nw every time I open it. Silly muscle memory.

Yup. Terminals ahoy.

> people didn't born knowing Javascript. They learnt it. And one could argue that Lisp is just as easy to learn

Just about everyone here knows javascript. Almost know one here knows Lisp, make your own conclusions.

You do realize this site was written in Lisp?

Unless the authors of the software behind HN make up a large portion of its comment contributors, I don't see the relevance.

Where did you get that impression from?

* Almost know one here knows Lisp, make your own conclusions.

nor English it seems :)

Still waiting for someone to correct the GP...

"No one is born knowing JS" or "No one was born..."

Looks like timmm isn't a native English speaker, should his command of English be more important than his message?

There are languages where "to be born" is one verb and it makes it reasonable to make the mistake and think that in english it would be the same: "to born".

I apologize if i came off as snarky. I was trying every bit not to. I didn't correct it immediately, but when i saw another user correcting, I added my own correction to his comment.

Btw, English isn't my first language either, so please do not see this as "arrogant English speaker wants everyone to speak his language". In fact, my mother tongue is far far different from english (we dont even have a common script!)

Emacs has pull down menus, cut and paste, CUA bindings, displays graphics, plays sounds...

WTF do you mean by "terminal-style buffers/frames?"

I don't mean to sound hipster or anything but I prefer software with native look-n-feel on the platform I'm using.

I tried Emacs on OS X (proglang on Coursera asks students to use it for editing SML), gave it a couple of hours and switched back to Sublime.

I understand I missed all its glory and power but at least Sublime scrolls like OS X apps scroll, has shortcuts like OS X apps and looks like a OS X app.

But then again, I understand why you might think this is a fool's position. I'm okay with that.

you ain't going to get native look and feel from atom.

Scrolling in WebKit is native, scrolling in Emacs isn't.

so write ruby or python for vim then.

not saying vim doesn't have it shortcomings, but people always forget that a scripting language for random app xyz still means you have to learn it's grammar. just like people who use ruby motion have to painfully learn that in the end while it looks like ruby it's still cocoa.

All programmers end up either learning or rewriting Lisp.

Just because people can program in Javascript doesn't mean they will be able to easily modify the code. Complicated code is complicated in any language, and Javascript in particular allows to write completely incomprehensible code that even pros would have trouble with. In addition, you'd still have to learn all the necessary APIs which might be harder than learning a new language.

Paradigm shift? I don't know, I've been writing desktop software in JavaScript for years now, it has its place but it also has big disadvantages yet, especially with accesibility stuff, which comes free if you use the stuff your OS offers for free.

  Atom is not only not open source but ...
Do you have a source for this? I'd be very disappointed to hear that if it were true.

EDIT: It appears that this isn't true. From a GitHub employee in freenode/##atom:

  <jonrohan> EvanDotPro: it will be open source, and other platforms, when it's out of beta
  <chance> jonrohan: where are you getting that information?
  <jonrohan> chance: i work at github

From Tom Preston-Warner: http://discuss.atom.io/t/why-is-atom-closed-source/82/8

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

Either jonrohan is misinformed, or he's using a rather tortured definition of "open source" - even the Open Source Initiative would disagree with that usage[0].

I must say, I'm a bit disappointed by the fact that Github doesn't seem to be on the same page internally about this; it's a rather important piece of information.


> not only open source

That means the opposite of what you thought it did :)

It was

> not only not

> Atom is free during the beta period.

Where does it say it won't be free after the beta period?

Well, one can only assume, based on the wording they use here:


> Atom is free during the beta period.

This reminds me of one of Mitch Hedberg's more famous jokes: "I used to do drugs. I still do, but I used to, too."

How refreshing, a correct usage of "the exception that proves the rule"!

And there goes four hours of my night to wikipedia

One can assume that, but that's not what it says. The statement that the editor is free during beta could mean "we haven't figured out whether to sell it after the beta, sell services around it, or develop integration with our other services and keep it free to enhance our overall value proposition."

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.

> http://discuss.atom.io/t/why-is-atom-closed-source/82/9

It's funny you say that, because as the only full time-ish developer of Chocolat, I could really use a lot of help!

There's ~600 open issues, my personal todo list alone is several years' worth of work. Too much for one man.


People make too much of open vs closed source. The real distinction is individual-lead vs committee-written.

TextMate, Sublime and Vim are good editors. But they are also Allan, Jon and Bram. Writing an editor requires good taste, accumulated experience, and a certain disregard for users' feelings.

You need someone who cares about the editor. Without that, you get a program where everything is wrong, but nobody ever bothers to fix it.

This is however a blessing and a curse. If the author can't financially support themselves, the editor will die. If the author becomes a millionaire, the editor will die. Thankfully, I'm still poor.


What are the 25 little things, by the way?

Haha, too much work indeed. :) I'm not going to list all 25 here, but I'd say the biggest three are definitely issues #1157 (this is HUGE, add a pref option please!!), #1369 (please!), and #1451/1417 (constantly crashing).

But overall, it's still just the most beautiful and elegant editor. :) Thanks for it!

Never heard of Chocolat before - but it is a very attractive OS X app!

Have you looked at Adobe Brackets? It's basically that, open-sourced today. Or look at node-webkit if you only want the app framework without the editor. The biggest downside I see right now is HUGE binaries (100+MB) because you're bundling a browser in your exe.

Browsers are 100+MB?

>> and it's in JavaScript, so it couldn't be easier for programmers in general

Because JavaScript is magically easier than any other programming language ever invented.

Even if this were true, it still wouldn't help an expert Objective C programmer with no JS experience hack on Atom.

Your bias is showing.

Adobe has been working on Brackets for a while, and it's essentially the exact same concept.

> But if Atom is ultimately just a big collection of straight-up node.js files, and anyone can go in at any time to change a line here or there -- and it's in JavaScript, so it couldn't be easier for programmers in general -- and there's no compilation step or anything -- then it's almost a fundamental paradigm shift for what desktop software could be.


> How I felt after that? I felt awesome. I had only installed Atom minutes ago. I didn't even had to think to fix my problem. All the knowledge I needed was already in my head! It was simple as editing a webpage. TL;DR: Atom allowed me to fix one simple problem – that I still encounter in most text editors nowadays – in seconds. What about yours?

You are so on-the-money about Chocolat. I love it except for the things that drive me crazy. I've been trying to love Sublime Text lately. Even though I see the benefits, I see the un-Mac-like-ness of it even more.

It's a benefit if your team uses a mix of Mac/Linux/Windows.

Oh don't get me wrong. The benefits are potentially huge. But it's also frustrating because I have decades of muscle memory built up that doesn't always work with Sublime.

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.

> Emacs Lisp has a lot of baggage and is nowhere near as widely used as JavaScript

Back in the 90ies, when I started using Emacs, Elisp had a lot of baggage and was nowhere near as widely used as Perl.

I'm still using Emacs.

That is also one of the ideas behind Light Table.

> A hackable text editor for the 21st century

I'll fix: A proprietary (unhackable) text editor that only runs on OS X.

I imagine that web developers will drool over this.

> A proprietary (unhackable) text editor

I developed some packages for HomeSite in the 90s. When HomeSite was integrated into Dreamweaver and development ceased, I realized that I had wasted my time developing HomeSite packages and that I should never again devote my time to extending closed-source software. Emacs has served me well ever since.

And it reports data to Google... http://atom.io/packages/metrics

But in fairness, they've fully listed the data being collected. I'm actually very comfortable with them collecting these metrics (though I'm glad there's a way to turn it off just the same).

- A unique identifier that is generated by computing the SHA-1 of the machine's MAC address. - The screen width and height - The version of Atom being used - The name of each item opened in a pane such as EditorView, SettingsView, and MarkdownPreviewView - The amount of time the current window was open for - The amount of time the current window to took to load - The amount of time the app took to launch

I'm almost comfortable with the choice of metrics, except for:

>> The name of each item opened in a pane such as EditorView, SettingsView, and MarkdownPreviewView <<

Why would they need to know my filenames?

I _think_ they're talking about the actual 'atoms' - that is the editor components. So the data that will be sent to google is 'EditorView is open', not 'EditorView contains these files'.

I might be wrong though.

You're absolutely right. We don't track individual filenames or data.

"If you do not want this information reported, disable this package from the Metrics section of the Settings view (cmd-,)."

Why should I have to opt out of metric gathering in a freaking text editor??

Because they made the program. So it's their decision.

If you want a program that turns this off by default, please feel free to create your own program with this feature disabled.

It's their decision to track their own users by default. It's anyone's decision to criticize them for their decision. That's healthy and much more efficient than for everyone to start creating their own text editors, payment systems, airlines or poultry farms.

I for one am more than fed up with hunting down and keeping up-to-date with settings for tracking "features" in every single piece of software I use.

And it's my decision not to use it. Why would I want a non-free (as in beer and speech) editor which reports data to Google, only works on Mac, and lacks any unique features? I don't understand the hype created on HN about it...

> please feel free to create your own program with this feature disabled.

I could do that very easily, if Atom were FOSS.

FAIL. A text editor with this default is just wrong.

Lots of assumptions here.

Where are you getting this from? I can see all the source at https://github.com/atom. Every repo I checked has the MIT license.

From Tom Preston-Warner himself: http://discuss.atom.io/t/why-is-atom-closed-source/82/8

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

However one tries to soften that language, that translates to a proprietary license of any standard definition of "proprietary"[0]

[0] It actually sounds rather similar to the old proprietary license that Microsoft used to use (not sure if they still do anymore).

Wow, this is worse than I thought.

If the source code is proprietary but GitHub accepts PRs from users, it means that users will be tricked into doing free work for GitHub and have no copyright claim on their work. From the discussion you linked, it seems that many people are happy about this unfortunate situation.

Can you build a fully functional version of Atom just from those repos?

To compare, Apple releases source code for some components, but they definitely don't distribute "/System/Library/Extensions/Dont Steal Mac OS X.kext".

I thought that file was a joke until I checked it and it actually exists. For those (like me) wondering what it does: http://en.wikipedia.org/wiki/Apple%E2%80%93Intel_architectur...

Oh my, "DSMOS has arrived" line (and subsequent freeze) is gonna haunt me for years.

The source of the actual editor isn't public.

From IRC: <EvanDotPro> it will be open source, and other platforms, when it's out of beta

There's real opportunity here for Github and I hope they take it.

Why is the basic workflow of the modern-day programmer split over multiple tools and over multiple systems?

Aspects of Github could be modularised and added to the editor while still keeping the underlying tool simple and this could change our user experience for the better.

Imagine flipping through your pull requests in the text editor and then seeing your friends comments and code reviews appear on top.

Imagine an issue being created on Github and the file(s) referenced instantly glowing.

This opens doors to thinking about the engineering workflow in a new holistic manner.

Why is seeing your friends comments and code reviews in the text editor any better than seeing them in the browser? Are we becoming this lazy? or this busy?

This is pretty shortsighted. It's not the simple case of "what you can already do with two tools" that we should be thinking about. It's that stuff that you can't even imagine was possible until it integrated, in the same place, and with a good user experience.

You'll have information that's right in front of your eyes where before, the tiniest wall of separation was barrier enough to make it inaccessible or out of mind. Things will become the same, instead of just both being in the same place. This is the essence of good UX, and it has nothing to do with this specific case, but it will emerge from simple cases like this. First two things coexist, then they share, then they become one.

For a while, the iPhone was just a phone and a computer. People even said the same exact thing you just did: "why is having a phone and a palm pilot in one device any better than having them separate?" Then they started sharing features, the internet became pervasively accessible. Then everything started sharing data and features. And now we can't imagine them separate, and we have an entirely new class of thing that came out of it that basically enabled a revolution.

Eventually programming could be the same. Programmers probably have the highest tolerance I know of for compartmentalization of tasks and poor interaction design and data visualization: they are extremely intelligent and have the ability to tie things together in their heads and break down tasks and tools ad hoc. But when you don't have to do that, when programming becomes easier and more fluid, things will start happening that simply couldn't before.

We can only dream of the kinds of advancements in our tools that are yet to come.

i see people saying less context switches. but isn't this the exact opposite? it's way more context switches?

isn't this the same as having our mails popup up notifications every so often or your gmail aggregating twitter and Facebook, because people thought it would make them more productive

You're creating a strawman. I can't see why Github would make the mistake you believe they'd make as they don't have the self-interest that Facebook and Twitter have in killing your focus with an onslaught of notifications.

I think you could expect all forms of notification to be hidden by default.

It would actually likely improve your ability to concentrate. You would be able to switch into another mode of a developers workflow without needing to context-switch onto an often focus-distracting browser.

Anyway, my core point was that there are a combination of features that allow the creation of a new holistic programming experience. I am not arguing its correctness and I am not arguing that it would suit everybody. :)

Exactly - making context switches cheaper isn't very helpful if you're doing so at the expense of making context switches more frequent[0].

[0] and easier to do "by accident"

This is a silly argument. You're all assuming this type of integration will be have the UI quality of your dishwasher.

Of course context switches and irrelevant information will be distracting if done poorly. This is a UX challenge—not a reason to abandon the idea.

Having the focus you need during concentrated tasks such as coding, while also enabling the integration of other tasks—such as high-level team context awareness and collaboration—is the key design challenge. Done well, it would be a killer app.

Done poorly, as with anything, it will fail miserably.

Programmers have a poor reputation for UI design prowess, and programmers tools are sadly usually made by programmers, and thus carry the same reputation. Very few amalgam programmer/designers exist to bridge the gap of motivation and ability to design a better toolset. But they do exist.

Let's be optimistic, shall we?

They're not quite the same. Those are push-notifications. Push/pull is orthogonal to what application you use for which purposes, especially if you have a desktop were you get such push notifications thrown at your peripheral vision no matter what application you're in.

Potentially fewer context switches and interruptions? I know for me the browser is a potential landmine of distraction, it might be handy to be able to limit that.

I think somewhere along the way we lost sight what context switching really is. Just because you put a different activity in the same tool doesn't mean there's not a context switch when you move to that activity.

Do you really think there's not a context switch when you change from writing and thinking about your own code to reviewing pull requests and comments?

There may be benefits to integrating extra functionality, but let's not imagine there's no cost to changing your mode of operation just because it's in the same tool.

Minimising context switching is a big part of improving programmer productivity, as I'm sure you're aware. This may not seem like much, but large increases in productivity can be achieved through small increases building up; every little helps.

Plus, it's cool.

I think you confused context switching with app switching. Yes having Github activity in the text editor means less app switching, but you are still context switching; from writing code to reading comment, which is the real productivity killer. Why not just add gmail to that text editor while we're at it and save ourselves some time?

Same reason there exist plugins to integrate Git status & diff in Sublime: it's useful for some of us.

IDEs, while they have fallen out of favor somewhat in the web development community, offer such a "holistic" development experience already - complete with deep integration into GitHub, in some instances.

I think you miss the point.

Being modularised allows the basic user experience to be kept very simple. It does not need to grow into something like an IDE. Hell, according to Packages [0] even tools like find-and-replace have been modularised so I do not think it follows that Github would carelessly decide to create a big ball of mud!

And additionally this tool has removed barriers that previously existed before.

Since it was created by Github they will be able to expose APIs to create features which are currently not possible.

Likewise the UI being implemented with WebKit means that the user interface can tightly represent what a user is used to seeing at different stages of their development process.

You might have read "The Design of Everyday Things" [1] before. There are certain elements which you need to control to create a good user experience: (1) discoverability, (2) feedback, (3) the conceptual model, (4) affordances, (5) signifiers, and (6) mappings. Without ease in changing the UI, and the possibility that Github will have self-interest in exposing extra APIs, it would be a lot more difficult to control for each of these.

It's just an opportunity to try new ideas. I'm not suggesting that this would be preferable to everybody.

[0] http://atom.io/packages

[1] http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d...

"Being modularised allows the basic user experience to be kept very simple."

The basic user experience does not exist; or rather it is trivially basic in any text editor. What's important is the advanced user experience, and it simply doesn't exist yet. For instance, Python support amounts to syntax highlighting; nothing compared to python-mode and elpy in Emacs, or PyDev in Eclipse.

There's also a large gap between the promise of "Full-featured, right out of the box" and offering fundamental functionality like settings-view and command-palette as extension packages.

What Atom has to offer, currently, is a bloated abuse of web technology with little appeal beyond Javascript hipsters.

This project has years of hard work ahead to begin competing with Emacs and Vim in some niches; hard work that isn't going to happen because it's proprietary software, and contributors will prefer the open source text editors.

> Since it was created by Github they will be able to expose APIs to create features which are currently not possible.

You're probably right, but even if this is not the case, they will at least hopefully have a better understanding of how to use the APIs well, given how often they work on and with their own APIs.

> There's real opportunity here for Github and I hope they take it.

I think the philosophy here is that there is a real opportunity and they hope that you take it (or someone in the community). They're creating a highly-hackable editor and their API allows access to everything you've asked for.

They're going to build a ton of add-ons too, but they want the community to build a lot of this stuff. The most creative product team in the world can't match millions of developers solving their own problems, so rather than try to build the perfect product for everyone, they're building the most flexible product for everyone to mold into what they need.

My hope is that the core of Atom isn't so bloated with GitHub integration and that integration is optionally available through the plugin management system. I'm of the type who prefers to use the text editor just for code and other tools for source control and project management.

>> that integration is optionally available through the plugin management system

Given that even find-and-replace [0] exists as a module I think you have nothing to worry about.

[0] http://atom.io/packages/find-and-replace

> Aspects of Github could be modularised and added to the editor while still keeping the underlying tool simple and this could change our user experience for the better.

This is essentially what we've done with some Rational tools (such as Team Concert) using by defining a set of loose-coupled RESTful capabilities for tool-based integrated, called OSLC http://open-services.net It has the nice quality, if adopted, as being able to link to you own issue tracker hosted elsewhere (bugzilla, jira, etc), CI, end-user need management, etc.

Atom has some limitations, I could see where OSLC and ActivityStreams would be a bit more interesting.

> Why is the basic workflow of the modern-day programmer split over multiple tools and over multiple systems?

I disagree that this is a problem.

Replace "programmer" with any other profession, and you'll see it's universally silly.

The more I see new editors floating around, the more I'm sticking to VIm. I am getting old, or it's a just a survival instinct.

On the other hand, the more the better, but we have already too many editors around.

I've sworn by SublimeText until now. And Atom is getting released during a time when I'm increasingly learning to love console-only computing. I envision a day when I can travel the world with a cheap laptop/chromebook and do all my coding remotely via SSH.. and Vim is very much at the core of that dream.

Now I just have to master it.

Try using the Vim plugin (Vintage or the newer one, Vintageous) with Sublime. That way, you can gradually get used to modal editing.

I worked like that for 8-10 months then made the switch to Vim. I've gotten so used to modal editing (not to mention window management etc.) by then, that I didn't even skip a beat.

This was my strategy when I switched from TextMate to Sublime a few years ago, the plan being to make the full switch to vim in a few months.

Sublime never gave me a reason to go all the way, though :p

I was like that while using ST2. But then better plugins started appearing for ST3 (the aforementioned Vintageous being one of them) so I switched to ST3.

But it crashed constantly; also, by that time the Vim emulation was really hurting me. The dot command was anemic, tabs were interfering with splits etc.

All in all, Vim was calling me, haha.

I've never though about that! But it sounds great! A question though... I don't know how much though you actually have put into this, but I'm curious. What do you consider a cheap computer?

I do all my coding (though it mainly web, which arguably might need less resources than other languages) in a medium tier pc. It's a lenovo B590 with an i3, 8GB RAM. It's not exceedingly fast but with two windows of chrome, 20 tabs each, 5 or 6 instances of PHPStorm open, and all the usual programs (email clients, dropbox, chats, etc) it still feels quite snappy.

The cost here in Austria was around 650€ or so in total, maybe less (I'm not quite sure now because I upgraded it little by little).

My question is if your plans are set around a dirt cheap machine that you "wouldn't care at all" if it gets stolen, lost or broken... Or something more in the lower middle class where you'd have to be careful not to lose one per month, but you could still run most of the stuff you'd actually need for local development.

This question arises mainly for my concern is greater about not having a working reasonable internet connectivity hence making it difficult to work over ssh, rather than the laptop getting stolen or broken.

> two windows of chrome, 20 tabs each, 5 or 6 instances of PHPStorm open

Jesus Christ, that sounds excessive.

Vim can be run well off of a $35 Raspberry Pie if that means anything to you. That machine has 512 MB of RAM. Basically every laptop will be able to handle it just fine.

Theoretically yes, practically it will be slow, but it's no the CPU/RAM it's the SD card (poor I/O speed) that slows down VIM on embedded devices. You have to disable swapping, you could load your current working dir to RAM and them write a script to save the data elsewhere but that's dangerous for production.

So the best device to run vim IMHO it's still a top-notch SSD-based laptop. A chromebook (intel-based to avoid other sort of issues) would be a better bet.

Yep, works just fine on my $200 Acer chromebook.

Don't dream it - be it.

I work this way most of the time now, regardless of which machine I am currently using: http://blog.schwuk.com/2014/01/15/chromebook-plus-digitaloce...

Here's a really interesting post about that: http://yieldthought.com/post/12239282034/swapped-my-macbook-...

https://github.com/fatih/subvim - unfortunately "Linux version is on the todo list, I'll work on it asap"

I do that currently, but using the local graphical editor. I just mount the ssh path to my local FS using Expandrive. It's not free but I can recommend it.

To be fair, an editor built on open web technologies could also be at the core of a dream to travel the world with a Chromebook.

If vim works great for you, then rock on! We can't have too many editors, though. Bad ones will fail to gain traction, and it's always good to get new ideas and modern techniques out there.

I am very excited about this, I love the Github team and this looks like a great tool.

My only question is -- why should I switch to this from Sublime Text? Are there specific use cases it handles better out of the box, or is it more of a modular base that will be expected to grow and outfeature ST2/3's seasoned plugin economy? I am very happy with Sublime Text now, but I would be willing to switch if either it gained a lot of traction, or could do stuff that I couldn't do with Sublime.

In practice, the ST3 API is extremely limiting and poorly implemented. The docs are both lacking and dated (read incorrect). It is trivial to crash ST3 by making the incorrect sequence of correct API calls. It is also common to resort to polling the editor to make up for other deficiencies. The API also only allows for extremely limited UI choices forcing highly unintuitive interfaces on end users. The ST3 runtime also features such gems as not shipping the ssl module on linux (while ST2 stripped out even more stuff).

I also expect NPM to be much better in practice than the sublime package manager which frequently ships broken code. JS is a better choice than python for async code which will make writing plugins easier.

Furthermore, ST is 3 people who largely ignore all feedback from the community regarding bugs and features. It won't be hard to out compete ST in the long run.

I don't know if I'd call it extremely limiting… there are some places I'd like to see more accessibility. However, I've built some pretty extensive stuff with it.

I would love to see ssl compiled in - I believe the reason Jon currently doesn't is that it would require building on at least 6 different machines to cover 0.9.8 and 1.0.0 (libssl.so.10 and libssl.so.1.0.0) for x86/x64 plus a customized version of ssl.py.

where on earth would a professional software developer find SIX different machines to run builds on??

Indeed. I tried to implement a fast project switcher plugin at one point; ie., a plugin to quickly switch to another window by autocompleting its project name, like super+P (instead of having to cycle windows or use the window menu, both of which are poor UIs when you have anything more than two windows open). But the API doesn't support focusing windows. You can switch focus to a different buffer in an arbitrary window, but it won't make the window itself active. I reported the limitation in the forums. Never got a response. Didn't surprise me; I have reported a bunch of other problems, hardly any of which received Jon Skinner's attention.

I've been using ST2 a lot recently and while I really like it, feature wise, I've had horrible issues with documentation. The big issue is that it doesn't seem to meaningfully exist, especially if you're looking to quickly start modifying things and creating new functionality. Maybe I missed the boat on it somewhere, but it's a nightmare to find anything out about it that isn't pretty simple. I've ended up doing a lot of digging through the keybindings, experimenting with random keywords, and reading other peoples code to get things to work. While that in and of itself is a learning experience (and there's something to be said about reading other code), it's hard to rftm when there's not really an m.

I guess it may be that my google-fu is just sucking lately, but the docs situation seems bad after a few weeks of using it. If I'm wrong and anyone has any suggestions, let me know and I'd really like to check them out.

This is dead accurate. I'm a huge fan of Sublime, but their API/documentation is an atrocity. As much as I love my current Sublime setup, if there were an editor with a well documented API for writing custom plugins I would switch in an instant.

Check out http://atom.io/docs/api/v0.60.0/api/. I've played around a bit in the beta. Debugging with the webkit inspector is nice.

What do you mean polling the editor? Are there any examples of plugins that do that?

I am a co-founder of floobits- https://floobits.com/about. We build support for real time collaboration into existing editors. I chiefly work on our editor integrations.

In terms of ease of development, the order goes like this: IntelliJ ~ Emacs > Sublime ~ Ace >> Vim. In terms of community and support, the former ordering is also true.


Here we are trying to get the Window, from the Sublime API. Sometimes it doesn't exist (even when windows are open). There is no reliable API to tell us when new ones are made or when old ones go away. Presumably, post_window_command (http://www.sublimetext.com/docs/3/api_reference.html#sublime...) would fire off with a close command, but this function has never worked.


Here is another quick hack polling the editor to know when its safe to call the sublime API: https://github.com/Floobits/floobits-sublime/blob/master/flo...

Here is a yet anther example needed for functionality and using callbacks to keep sublime from crashing: https://github.com/Floobits/floobits-sublime/blob/master/flo...

Here is another example of pure craziness forced on us by ST3. We need to patch Views, but ignore our own patches (locally) so we don't form an echo loop. We also need to move the cursor so it doesn't jump. Sublime deals with these changes so poorly, we are forced to jump through hoops. In contrast- emacs/vim/intellij are basically fine just dumping on the entire buffer.


I believe the main benefit is that it is much easier to customize/change/tweak.

I don't see a reason to take that as a given. This uses node, ST uses python. Sublime plugins have a huge amount of power and python is certainly not terrible to work in.

I've been playing with it for a few minutes now, and it's definitely the case that it's easier to tweak. Not because of the underlying language, but because they expose so much of what's available through a GUI.

I'm blown away by how cool this is. I'm just really hoping for good Vim keybindings and I will pay good money for this once it's out of beta.

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

Yeah, Vintage mode was okay. I liked the Vintageous plugin a bit better but even that left me wishing for Vim some of the time (more time to adapt might've helped).

Other than that, it seems like an incredibly well-designed editor. Really looking forward to seeing what happens to it now that it's out in the open.

You may have found it already, but there is: https://github.com/atom/vim-mode

Yup, saw it and looking forward to trying it (haven't yet). But just reading through the description made it clear it wasn't quite ready yet.

written in Coffeescript? Oh God how did we get to this...poor old Vim...

Lots of work to be done in the vim department: https://github.com/atom/vim-mode

You've been playing with it? How did you get your hands on a copy?

I signed up for an invite less than 1 min after I saw the first mention of it on twitter (https://twitter.com/defunkt/status/438789450147979264) and received the invite maybe 15 minutes or so after that.

I was given 3 invites, I gave away 2 but I'll give the third to the first person to email me. (EDIT: gave away the last one)

Doesn't seem like they're keeping too tight of a lid on it, but I guess we'll see. It seems like it can be freely passed around; I think they're just trying to gauge interest since it won't be free after the beta period.

It's also open source, so maybe we'll see some creative hacking to the core.

Look downthread, the core is not open source.

Ugh. :(

This appears to be free. ST is free but makes me feel bad about not paying for it every few saves.

Only for now https://github.com/atom/welcome/blob/master/lib/welcome.md

    Atom is free during the beta period.

I'm guessing they might include this as a feature with private repositories.

That's because ST is not free.

I like sublime, but my primary computer has an ARM processor and there is no sublime port. The sublime developers have stated that they don't have the bandwidth to handle an ARM port, and that's fair. But I find it difficult to justify paying for a license, when I can only use the editor ~25% of the time. An editor that is sublime-like and works everywhere would be awesome. I can't tell if atom has this, but a hosted version would also be cool, allowing users to hop on the service and do some quick work when on unfamiliar machines.

'Primary computer is ARM' - and you are a developer? I'm genuinely curious about your setup & work.

I do fair amount of work on my Chromebook, granted I work mostly with Rails apps, so I can just connect to my server and do my stuff over SSH


Yup, the Samsung model. Use it for most of my work. I've got an old clunker that is x86, but that thing is showing it's age so only use it when it's absolutely necessary (when there is no ARM port for an application i need, for example). The battery life and weight/size of the chromebook are really awesome. Using crouton to run an OS is pretty painless, although you do run into a few bugs every now and then. Also, the hard drive needs to be supplemented with and SD card. But for the most part, works as good as a MacBook Air for a quarter of the price.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact