Atom
atom.io
atom.io
------
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.
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?
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.
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
This "master programmer" need to stop abusing his novices, stop resting on his laurels and get back to some learning.
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".
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'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.
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!
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.
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.
⌘-Z should have been adequate.
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.
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.
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.
> 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.
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.
Hopefully I never have to use it, but pretty cool none the less.
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.
http://vimdoc.sourceforge.net/htmldoc/undo.html#undo-persist...
...I'm sure Word will catch up eventually.
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.
This has saved my butt a number of times.
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 ]
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
Side note: Neither of the two issues you mentioned are "one of humanity's biggest enemies to progress."
"Ignorance is Strength" (1984)
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.
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.
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.
Careful, that is quite a slippery slope...
File > Revert To > Browse all versions
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.
Maybe you find it one day trolling through the menubar. Maybe you don't.
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'.
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.
http://shiftleft.com/mirrors/www.hpl.hp.com/personal/Alistai...
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.
http://office.microsoft.com/en-us/word-help/track-changes-wh...
Inexpensive and truly unlimited storage. Windows, OSX, and Linux too!
No offense, to you or your wife, but this statement is hilarious for several reasons!
------
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.
Also, https://xkcd.com/927/
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.
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.
Where does it say it won't be free after the beta period?
https://github.com/atom/welcome/blob/master/lib/welcome.md
> Atom is free during the beta period.
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.
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.
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.
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.
$('#element').hide();
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.
Myself included (:
Just about everyone here knows javascript. Almost know one here knows Lisp, make your own conclusions.
nor English it seems :)
"No one is born knowing JS" or "No one was born..."
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".
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!)
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.
But like all editors, they have to have some clear advantages and a community, or it's not a viable option.
Crafting iOS Dev Tools in Redcar - Delisa Mason (#inspect 2013)
WTF do you mean by "terminal-style buffers/frames?"
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.
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. :)
Atom is not only not open source but ...
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 githubThat means the opposite of what you thought it did :)
> not only not
> 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.
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.
http://discuss.atom.io/t/atom-is-so-powerful-that-it-blows-m...
> 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?
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?
But overall, it's still just the most beautiful and elegant editor. :) Thanks for it!
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.
I'll fix: A proprietary (unhackable) text editor that only runs on OS X.
I imagine that web developers will drool over this.
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.
To compare, Apple releases source code for some components, but they definitely don't distribute "/System/Library/Extensions/Dont Steal Mac OS X.kext".
> 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).
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.
If you want a program that turns this off by default, please feel free to create your own program with this feature disabled.
I could do that very easily, if Atom were FOSS.
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.
- 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
>> The name of each item opened in a pane such as EditorView, SettingsView, and MarkdownPreviewView <<
Why would they need to know my filenames?
I might be wrong though.
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.
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.
[1] http://www.amazon.com/Design-Everyday-Things-Donald-Norman/d...
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.
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.
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.
Plus, it's cool.
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
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. :)
[0] and easier to do "by accident"
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?
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.
Given that even find-and-replace [0] exists as a module I think you have nothing to worry about.
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.
I disagree that this is a problem.
Replace "programmer" with any other profession, and you'll see it's universally silly.
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.
On the other hand, the more the better, but we have already too many editors around.
Now I just have to master it.
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.
Sublime never gave me a reason to go all the way, though :p
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 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.
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.
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.
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...
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.
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.
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.
Vintage mode in ST2/3 isn't perfect, but it's pretty solid.
Atom looks interesting. I really look forward to trying it out.
I'll have to try that out again
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.
Atom is free during the beta period.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.
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.
POLLING:
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.
https://github.com/Floobits/floobits-sublime/blob/master/flo...
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.
https://github.com/Floobits/floobits-sublime/blob/master/flo...
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.
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.
BTW, I'm less concerned and more just surprised to see Google Analytics used like this. I guess it really is the blurring of the lines between desktop and browser-based apps.
Maybe this GA usage is not unique, but it's new to me.
You are, though it's mentioned on the very first screen that pops up when you open the app: https://github.com/atom/welcome/blob/master/lib/welcome.md
More data going to Google without opting in first? Bummer.
echo '
127.0.0.1 ssl.google-analytics.com
127.0.0.1 www.google-analytics.com
127.0.0.1 google-analytics.com' >> /etc/hostsAre any of us so self-important, that we think our usage stats for a text editor are some kind of top-secret data?
I mean, come on - it's a text editor - I edit my scratchpad and my coding projects on it.
If any of the stuff I had was that top-secret, I'd be doing it in a digital clean-room, with an airgap. And I'd actually have top-secret clearance.
How many of us here actually have top secret clearance? I'd bet very few...lol. And I doubt they'd be posting here, or admit it.
My list of text files I have open is quite frankly, is not that interesting. I don't really care if Google wants to mine it. Or if Github finds out I edit a document called "Lolcat images" fifteen times a day. I seriously doubt any Githubber is going to be sitting there, pouring through logs looking for salacious information about the documents I edit...
It's not about a big government spying conspiracy. It's about basic privacy and not giving out data about yourself that you don't want to give out.
There are also enormous trust implications.
It's fine to say, oh but the privacy! But that in itself isn't an argument. It's just an appeal to emotion, with no facts.
What do you think will happen if Github has usage data on how you use their text editor?
Or what do you think will happen if Google knows what websites you search for?
These aren't rhetorical questions - I'm actually curious what scenarios people actually think will play out.
I find it unlikely that Google/Github would publicly publish that information on their websites. I also find it unlikely that an individual person would ever view your data.
What other scenarios do you believe will happen?
Now, if the government were involved, that's a completely different kettle of fish.
How about: I don't like to be watched. That's a fact, though I'm sure you'll dismiss it as an appeal to emotion.
As individual data points, I doubt we're that interesting.
It's like NetFlix knowing what movies I watch.
I doubt any single NetFlix employee could give two cents that Victor in Australia likes watching Once Upon A Time. (Awesome show, btw).
However, if I watch Once Upon A Time, and I also watch XYZ, and then other people do the same, maybe they get to improve their algorithm. Woot to them.
Maybe Github want to know what features get used. Or what performance issues people are experiencing.
Maybe it's definitions, but I don't consider this watching - they want to know what we do as an aggregate, but it's not like there's a little imp beside me watching me as I type.
(Although I get how some people might feel that way, if it's just a black box to them).
These organizations, and those capable of secretly subpoenaing them, have software and very fast computers that do the watching. And it's not watching, it's profile building.
I'm not saying that this editor's phoning home of usage statistics is resulting in you being on the no-fly list, but you're argument is missing the point.
What do you think they will do when they have built a profile of you?
Actually, I don't think it's even a huge secret that companies have profiles of customers/users.
Google has a profile of you - and they build targeted ads. I don't see that as particularly evil - Gmail is ad-supported, and I'd rather those ads were relevant to me, rather than endless adds for Cialis (I have no idea what that even is), or for formal dresses or hair extensions.
Github probably has a profile of me - they use it to recommend repos they think I'll be interested in, and keep me coming back to the site.
Microsoft undoubtedly has a profile of me, Yahoo has a profile of me.
Even my supermarket, if I bothered to sign up to their rewards scheme, would have a profile of me.
My credit card company has a profile of me.
All of this is public knowledge - in fact, I think it's better that this stuff is out there, companies acknowledge it and people are aware of it.
Anyhow - to the point - what will happen when these companies, who sell products and services, have profiles of you?
To me - the likely outcome is - they will try to target you better, and get you to buy more products/services.
Can you think of any other likely scenarios?
That being said, it's no stretch to understand that some people just don't want to volunteer personal information especially originating from software.
There are enormous trust implications with any sort of software that phones home for any reason. And if the software source code isn't publicly auditable it can be impossible to actually verify what information is being sent from your machine. I personally don't think it's possible to actually trust closed source software. I don't care that it's socially normal to ignore your personal computing privacy. I care about mine.
As I said, there were two scenarios that I outlined which were unlikely - Google/Github posting my text editor usage publicly on their website, linked to my name, and employees of those companies individually trawling through.
The scenario of them mining for trends in the data, in order to improve the software, I'm perfectly fine with.
The scenario of the government being involved - I agree that's bad - however, we haven't seen any indications that is true for the wide public.
Can you actually come up with any other scenarios that are both 1. probably and 2. worrying?
It's not about tin-foil hats or being uptight, it's about my-personal-data-privacy and network-user-best-privacy-practices.
At this point, you either don't get it, or you don't think I should have the right to absolute data privacy if and purely because I want it.
If you do draw a line somewhere -- anywhere, really -- then I'd suggest you're just like everyone else who thinks that privacy is a right and it can be violated. You just draw the line in a different place.
If you really do think that any kind of data collection whatsoever is fine, then I'd just say I don't think many people would feel comfortable with that, not even serious law-and-order types. You're entitled to give away your own rights, but not mine.
This is Github collecting usage metrics for their text editor. It should be fairly obvious to any programmer why they're collecting this information - it's to improve the product (which they will probably then sell).
The other thing is, Github is doing this in aggregate, and de-personalised.
But can you think of a single reason why a company like Github would want to collect, as you say, my password information, or webcam shots of me?
Apart from the stupid amount of bandwidth and storage they'd need to transmit and store webcam footage from all their users - what exactly could they gain from this?
What's the business case? How exactly would it make more people pony up money for Github subscription?
Since that's sort of their goal - to make money.
People seem to think there's some grand Illumati global conspiracy going on. There really isn't.
It's actually a lot simpler - this is capitalism, and companies exist to make money (within the bounds of the law).
If it makes them money, they'll probably do it.
If it doesn't, and it's "evil" they won't just do it for kicks of being evil. There needs to be a business case.
Somebody has to justify to their manager, who will then justify to their manager, why something will add value. Surely you've experienced this?
Now, I draw the line at the law, really - so if companies are fraudulently charging things to my credit card, or threatening to shoot me if I don't buy their product - yeah, that's illegal and I don't like that.
But if they're operating within the bounds of the law, or even if they're just being annoying and shoving ads in my face, I'll either put up with it, to use the service, or just use a different service.
As I said in a parent comment - the government is a completely different kettle of fish. However, companies are pretty easy to see through - their motives are, at least on a general level, pretty well defined.
"The other thing is, Github is doing this in aggregate, and de-personalised." - THEY SAY.
"What's the business case? How exactly would it make more people pony up money for Github subscription?" - Companies can and do use any information gained about you to build a profile about you. They use this profile to do things like target you ads as well as sell your profile to other companies.
"People seem to think there's some grand Illumati global conspiracy going on." - No we don't, this is about basic privacy best practices.
"If it makes them money, they'll probably do it." - Exactly.
"There needs to be a business case." - There is always a business case. "Business Case" is an abstract concept.
"Now, I draw the line at the law" - The law is an enormous grey area. Essentially you haven't drawn a line. What you've argued is against identity theft and violent threats, not privacy protection.
"But if they're operating within the bounds of the law" - In a democratic society, these things are for us - the society - to decide and change. If you don't agree with the bounds of the law then it is your duty to act accordingly. Arguments like, "as long as it's not breaking the law" have very little use in a democracy.
"government is a completely different kettle of fish" - The government can secretly subpoena these companies for any information.
"companies are pretty easy to see through" - That makes no sense. I get what you're saying, they're trying to make money. There is no one size fits all strategy for making money and businesses do what some people consider "the wrong thing" all the time in effort to just make money.
-----------------------------------------------
People here are concerned about basic privacy best practices, not companies making money or governments spying. No one here is worried about some grand conspiracy. There is absolutely nothing wrong with not wanting software that is running on your own personal machine to send statistics about you to a third party whether they are purported to be anonymous or not. It's unfortunate that the societal norm is to turn a blind eye to these basic best practices, but it doesn't mean that those of us that still respect them should too.
The concept is this: Trusting closed source software is not something I want to do.
Not: Github is going to fuck me in the ass if I let them see my usage statistics.
My premise is that my life isn't that interesting, and if Github wants to track how I use their product, then sure.
Heck, if they send me a survey, and I can be bothered, I'd probably even fill it in with - this is how I use your editor, this is how you can improve it (in my opinion).
If they can just collect that information for free, with no effort on my part, sure.
No? I don't see how what I said agrees with you in any way.
Who wants to eagerly track my life? I'm confused what you mean here.
Is GitHub meant to be "eagerly" tracking my life? As far as I'm aware, and what I stated was - they seem to be mining for usage data.
It's the same way that www.github.com has GA enabled, to see what pages people go to.
Is my life more interesting that I think? =)
That would be pretty cool, but as far as I'm aware, I'm not some super-special VIP...haha.
Google analytic is everywhere. If you don't want Github to track you, then don't use it. So if people fear Google, then should Github do the tracking on its own? Then all the sudden Github is not evil anymore. But look: github has your repository, your code. If you have a private repo, github still owns the source code in their data store. So in the end, privacy on Github? Minimal.
And you know what? Github itself has been using Google analytic for years. And now we are complaining about Google collecting data?
If you care about privacy, you shouldn't even be using Github. If you care about your privacy, you should never give up your true IP, your true identity on the Internet.
First, it is not "evil", it's just an invasion of privacy. Yes, if GitHub did their own tracking I wouldn't have a problem with it. What I don't want is one company that knows everything I do online and that's why I have a problem with GA. That GitHub tracks my activity on GitHub is completely acceptable.
> And you know what? Github itself has been using Google analytic for years. And now we are complaining about Google collecting data?
I can block GA in my browser, so this doesn't concern me. Using privacy invading tracking scripts all you want, I'll just block them. Can't really do the same in a desktop text editor.
That said, it would be fairly simple to have a variable for super that resolves to ctrl/cmd on other platforms, the same way that most download pages nowadays infer your platform and show you the binary you most likely want.
>Atom is a desktop application based on web technologies.
This.
Any tricks for getting one?
> Like other desktop apps, it has its own icon in the dock
it looks like it's osx oriented.
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.
> javascript
Choose one.
commit 9d7895c567e8f38abfff35da1b6d6d6a0a06f9aa
Author: Ryan <ry@tinyclouds.org>
Date: Mon Feb 16 01:02:00 2009 +0100
add dependenciesGotta keep it relevant!
[1] https://github.com/defunkt/coffee-mode/commits/master?page=7
I can see a huge compromise in hackability - its core is closed source.
But they are the venture invested company now. Need to show returns 10 to 100x the investment in a few years.
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.
The one thing that really excites me is how people getting into programming could start off with a pretty basic editor and add and write packages as they hone their skills, ending with something incredible powerful and tailored to them. In fact I'd really love to see a super customised starter version for children / beginners that acts as a learning aid as well as a text editor.
No doubt there's going to be haters in the vim / emacs / ST / insert favourite editor here camp but I really hope this works out for the Github guys (and I have a feeling it will).
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 are worth looking forward to if the API is more extensive than Sublime. There is too much you can't do in Sublime Text plugin authoring.
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.
Hacking the minified source isn't going to be fun no matter what, but if you clone Brackets from git the original LESS files are very easy to modify. Or you could just write a three line extension (https://github.com/adobe/brackets/wiki/Customize-Your-Code-F...) to adjust the CSS without modifying the core at all. That flexibility is the advantage of building on the web tech stack (an advantage shared by Brackets, Light Table, and Atom alike).
But who's going to buy an editor that can't even open a 1 MiB file? http://discuss.atom.io/t/unable-to-open-files-more-than-1mb/...
Moreover, besides code posers and managers, who is going to throw away all their knowledge and time configuring the editor they were using?
Closed beta, that too.
I mean, it looks nice - but I'm a bit undecided about the whole proprietary code project thing.
If it was open-source, we might actually be able to see if there was some silly hardcoded limit in there - heck, we could even submit a patch and do a pull request.
That, and the blatant ripping off of Sublime Text's interface.
It's bad enough they don't put the source itself on Github, but they aren't even using Github's issue tracker for the project - or heck, any other issue tracker as all.
So we're resorting to filing bug reports on a discussion forum...shakes head.
Hopefully Github will come through, and sort things out.
I have no objections to paying for an editor - heck, Sublime is $70 - but with this being closed source, and Brackets.io being more mature, and open-source, not sure what the attraction is.
>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 scripting languages.
It doesn't seem like they (and many others) are denying that Emacs and Vim are excellent editors. Why is ease of use such an important issue for text editors? Emacs isn't terribly difficult to use, but if my livelihood and the majority of my time is tied to what tools I use, then it's worth the investment of time. I don't think I've met an Emacs user who has put in the effort of learning Elisp and customizing Emacs to their liking ever deny the benefits of learning it in the first place. Yes, it's a pain in the ass initially. I quit Emacs twice before I became determined to stop whining and spend quality time learning about tooling.
There is no doubt that Emacs has a steep learning curve and perhaps that's because its developers have a higher expectation of its users. I would argue that these expectations are easily matched by the capabilities of a competent programmer.
This ludditic reverence for user-hostile text editors is one of the more perplexing and frustrating things about our industry.
Are you suggesting that it isn't in Emacs?
Well, I remember using Emacs for the first time. It opened up and I started editing the opened file. I saved the file from the file menu (which also showed me the shortcut for saving the file the next time I have to save something). Done. Now, this is exactly what a novice would do with notepad.
I found that many people 'demonize' Emacs just because they found it unfamiliar. Sure it's unfamiliar. For about a day. Then, it's just as familiar as any other user interface. I now used Emacs for, well, the shell, the dired and wdired, multiple cursors, keyboard macros, project-wide grepping and everything in between. Getting familiar with the editor was a great thing to have done, however unfamiliar it was in the beginning.
With the benefit of hindsight, I can truly say that learning how to properly use a text editor, especially one so powerful as Emacs, is the one thing the any programmer absolutely must do. So, even if the editor isn't "anything other than immediately intuitive", it's still a good idea to wrap your head around the non-intuitive things.
> Are you suggesting that it isn't in Emacs?
> Emacs is obviously and inarguably not immediately intuitive.
"obviously" : I find it anything but obvious. "inarguably": Really? So it can't even be argued? Well, I don't know what to say to that.
I feel the same way about our industry's enslavement to faddishness.
It is fast enough for every job I've ever thrown at it... Do you only want there to be one programming language or something.?
This coming along scares me that an already tenuous situation around the future of Sublime Text may implode due to this new editor... and it isnt even open source. I'd rather build my own highly customised GUI+CLI macvim/emacs with both python and JS plugin backends than switch from one closed source editor to another just because its new and uses Node... I dont normally swear on hacker news ... but fuck that shit.
If an unknown third party came up with Atom it would have never gotten that attention.
ST3 is a very good product viewed from any angle and VIM either—it will be hard to beat these reference products. I love Node/npm and again the stack sounds great but I don't know if this stack will be much easier to extend than something like ST3 or VIM.
What I have seen from a product perspective on the Atom landing page does not blow me away, not at all. And it is wether free nor open source.
But it's from Github and that's reason enough to vote it up.
Others noted that the source mentioned "free during beta", I certainly hope that's not the case and it's truly FOSS. Sublime Text development has slowed significantly recently and the community can't continue to drive it since it's closed.
Funnily enough, Sublime Text was born out of Textmate development slowing, and I can't seem to shake that vibe here too.
(Light Table itself is written in ClojureScript, which is a bit idiosyncratic, but it's hardly worse than Elisp, and anyway you can write plugins in normal JavaScript.)
<DouweM> kevinsawicki: is the actual core going to be OS?
<kevinsawicki> DouweM: not during the beta
<tyOverby> How is atom both invite-only and open source at the same time?
<avidal> tyOverby: the engine isn't open source (or at least yet)
EDIT: Plus, if an editor is going to join the ranks of vim and emacs in history (something which neither Sublime nor TextMate are on track to do) it has to be open source. Anything else and it's just another product.
Tools work in a strange way. I recently saw a whole team of embedded developers use TextPad. They haven't heard of anything called 'vim' or 'emacs'. From their perspective its either a vendor supplied IDE or TextPad. One of them was even startled to see this shiny new thing called 'Sublime Text' when I was using it. He went out with enthusiasm, but was hardly able to convince any one to use it.
A code editor with first class prominent Github support is more likely to encourage creating Github accounts - it would just work. Compare to regular code editors which require jumping through various hoops (typically having to find relevant plugins, install them on all machines/users, and then figure out how to use them as they are extensions not core).
A pitch of "if you use this editor then all the team's work is automatically synchronized and available" is a very powerful sell.
Not for me. I do like to give new editors a try (fell deeply in love with LightTable just a short while ago), but OS X as main platform and yet another closed editor?
Only? I can point to a large number of Python, Ruby and Perl plugins for Vim. Unless they are considering those special-purpose and nodejs is the only truly flexible scripting language.
Some of them look quite interesting already.
Atom is eventually a dead end. They are paying lip service to eventually partially opensourcing it.
It is the opposite direction of the magic of git, which enables easy sharing and collaboration.
Beware the promise of later opensourcing of projects. Without an early commitment, the developers of atom will invariably include proprietary software to ease development which will preclude later opensourcing.
You are better off taking the hard road and investing your time in tools that are not cargo cults.
http://www.reddit.com/r/programming/comments/1z0ykn/atom_lau...
Almost every single comment is negative, dismissive, one liners filled with half truths and very few child comments seek to rectify any misinformation or support a discussion.
The first and by far most-upvoted with a 700 point margin.
>I must be out of touch with modern development. I don't understand the thought process that leads people to be excited about a closed source, node.js text editor that reports your usage to Google.
It suggests the user simply scanned over other comments, glanced at atom's site and proceeded to regurgitate karma bait. I suppose it says a lot about the attention span of these people as there are also highly voted "tl;dr" request comments.
A perfect example of misinformation:
>[ unquietwiki 70 points] Isn't Brackets this already? Node.js/Chromium app with plugin support? > --- [ MrSenorSan 67 points] yup, but atom is not open source yay! wait a min... > --- [ kmeisthax 17 points ] Yes, but with Atom, you have the priviledge of paying GitHub money for a software product in a market with numerous competent free and Free Software options.
The supply of vitriol is unending.
It was the same with the /g/ thread, though surprisingly not quite as bad.
http://archive.rebeccablacktech.com/g/thread/S40550074
My point is, stay classy Hacker News. While you may even have similar opinions with these communities, the reception in this thread has been far more exciting and you put effort into your discussions. The contrast is massive, and especially interesting considering this is one the highest upvoted articles on HN, sitting alongside Neovim. suggesting we desperately want to replace our editors.
I don't know, I can't see how this is a priority for them...
As for how it could commercially benefit them: similar to how Chrome benefits Google.
Compared to that, a text editor is a mere bagatelle.
This said, you can also write lighttable plugins in javascript.
http://atom.github.io/space-pen/
I bet this space-pen DOM DSL would mix well with the React virtual-DOM approach.
Or are just the plugins/extensions written in Javascript while the core editor is in C or C++?
Obligatory: People who got a beta invite, anyone feeling generous and want to give me one? (As I understand it, when you're invited you get a few to hand out, too.)
I'd imagine, all of this is written in Javascript and compiled/rendered with v8.
Seems transparently under-handed to me.
It'd be nice to see the backend be a drop-in replaceable API so it works just as well hosted in a browser/on a Chromebook/in a NodeJS process.
That's only one piece of making an editor run in-browser and cross-browser of course, but it's an important piece.
Also -- there are actually a couple ChromeOS ports of Brackets out there already (such as Tailor - https://chrome.google.com/webstore/detail/tailor/mfakmoghean...), but I'm nto sure if any of them are being actively maintained.
Couldn't get it to work on Debian Wheezy yet (GLIBC_2.15 not found)* but worked on a Windows machine at work so I'm testing it there. I'll get back to linux later. Looking forward for v1.0. :)
* It seems to be a known issue: https://github.com/LightTable/LightTable/issues/972
Pair editing.
Specifically, having the ability to pair two editors over a network and edit the same set of files.
Lots of other editors do this, but here's the key: Each editor keeps its own settings and environment.
I'm a vim guy. I can set up my Atom to be vimlike. My buddy, the Emacs (heretic!) guy, can set up his Atom the way he likes, and we can work in harmony.
That's all I want.
- Soft undo for multiple selections.
- Search settings since the panel is overwhelming.
- Markdown preview should be updated live?
- I really miss Go To Anything from Sublime Text 3.
- You should be able to select the syntax highlighting from the status bar.
- Inline preview of audio, SVG (toggle?) and fonts? That would be rad.
- Syncing of settings using GitHub settings?
But other than that this is really good progress!
I'm pretty sure it's one of the reasons to come up with its own desktop editor (that later can be also used online) -- to bridge the gap.
That being said, anyone with a spare invite? :) Ta.
I'm extremely comfortable with vim. I can cruise seemingly at light speed and have just never been able to find a text editor which offered the same level of productivity when jumping back and forth between the mouse/trackpad and keyboard.
However I just couldn't resist the urge to try out a new text editor that was created by github and thankfully I scored an invite from someone on twitter.
I've only had the thing open for about 10 minutes and already I'm impressed.
It allows me to write in markdown, save the file, render the markdown into markup, and then launch the webkit dev tools to inspect the rendered DOM.[0]
Do other modern text editors such as Sublime Text allow you to render the markup and then inspect the DOM with browser dev tools? If not that alone seems like a pretty good innovation.
More Info: [0] https://pbs.twimg.com/media/BhdTeedCcAARgYV.jpg:large
Thanks Github!
Seems like vim isn't really for someone like me (I haven't studied PhD level computer science and I don't write compilers and/or lisp interpreters in my spare time for fun).
My point is that I can load up Sublime Text or Brackets or this (maybe?) and work in a very efficient way.
Put another way: working with Sublime Text and Adobe Brackets is a good experience for me... There's nothing that screams out at me "Man, this sucks, I need to go learn vim."
Of course, PHP people probably said the same thing when Rails came out. The difference is that current GUI editors are already very advanced. I'm skeptical that I would get any efficiency boost from vim (at least anytime soon).
vim has nothing to do with PhD-level CS or writing compilers and/or lisp interpreters. The Emacs community might fit that stereotype a little more but really not much more.
Vi (vim being 'vi improved') is great because it works on basically any terminal. It works with my iPad's keyboard and with a teletype terminal from the 70s or 80s, as well as a normal PC keyboard. Emacs has similar brags.
The terminal's not going anywhere and if you like keyboard shortcuts, knowing five or ten that will work on any keyboard in existence for an editor that is on most unix systems you'll find has some value.
Also, I do have a mac, so maybe I'll check out vimtutor.
My point is that I'm very new to programming, and it's so much easier for me to load up Sublime Text and start getting work done. At least for now, learning vim would be something that get's in the way of learning/making. It also doesn't seem like the benefits would outweigh the cost.
I'd say give Vintage mode on sublime a shot. It does the basic keybindings/motions of vim and will give you an idea of whether or not you might be interested in it. It's also nice because in insert mode it's basically just normal sublime, so you can just switch back to that if you get frustrated.
Are you on linux, osx, windows, or something else?
If you use vim/vintage mode, remap capslock to be escape.
This took me forever to figure out, for whatever reason, but if you're on windows, the easiest thing to do is get autohotkey [1] and write a script with one line:
Capslock::Escape
You can compile that to a portable binary and use it anywhere as well. It's really straight forward.
I also added two keybindings to make Alt+movement to add cursors above and below: { "keys": ["alt+k"], "command": "select_lines", "args": {"forward": false} }, { "keys": ["alt+j"], "command": "select_lines", "args": {"forward": true} },
It doesn't always interact naturally with vintage/vim mode, though, but that was just a personal preference.
Then one day you're riding herd on a flock of zLinux images and troubleshooting boot problems through a 3270 terminal with (s)ed as your only friends.
We'll see if one of these console editors finally sticks.
It looks like the GH guys have worked around this problem quite well, and I'm looking forward to begging, borrowing, and then just begging again if I get a chance to try it out.
Not sure if that's an unfounded fear, but I don't want to invest time customizing a platform and writing plugins when it could close shop in a second. I suppose I could say that about a lot of things I do customize, but it's hard when the FOSS text editor world is so rich.
On top of that I can be up and running with Emacs on a fresh install of just about any linux distro: install via the distro's package manager, drop in my configs, done.
One thing that is conspicuously absent is any mention of it being open source. I can certainly appreciate that Github is for-profit, but I would love to have a clearer idea of how free / not-free this tool will be when it is publicly available.
Take the overall diff bar of most IDEs for example (Jetbrains, Netbeans, etc.). I want that in Sublime/Atom. There is a plug-in for Sublime to show diffs per line, but no way to manipulate the mini-map to show diffs at a glance.
http://blog.jetbrains.com/pycharm/files/2013/12/2.png
Edit:
See, this is inferior and what Sublime Text already has: http://atom.io/packages/git-diff
What's superior is a full-blown diff bar overview of the file.
What most people wouldn't like to see are yearly subscriptions of another editor or paid upgrade every 18-month. I could personally bear with textmate and sublime for their current licensing (personal => works on as many computers I have - which I have at least 4)
For OSS ones, we have the traditional ones like emacs, vim, eclipse, and newer ones like brackets (which also sold as paid editor as Edge Code CC), lighttable or google's half-baked collide.
People at GitHub are also great, well funded, but this is not their core product. Do they have a leader -I don't know if they have or not- who will be focusing only on this product and keep up with jskinner?
I am sure Atom will be around for long years, as well as Sublime Text. Thanks to GitHub, I am looking forward to give it a try.
As an Emacs user, I find it funny to hear 3-5 years be referred to as "the long run".
Also, Sublime Text won't be leading until it has a package with more features than Org mode. ;-)
I am not arguing that Sublime Text is the best -because I am not that pro-, but I can assure you it is hot right now, all around the world. It may be wrong, but all cs students and developers I personally know in 4-5 countries use it, like it. Most of the online courses tell their students to use it. It is highly recommended, all over the web.
The word is spreading.
http://www.google.com/trends/explore#q=%2Fm%2F01yp0m%2C%20%2...
What other text-centric apps can be made better by a browser framework? Maybe the terminal?
It's not a good idea, but given the abysmal state that desktop apps seem to be in at the moment[1], it's probably the least bad idea.
[1] Been about 5 years since I did a desktop app, but if anything they look to be getting worse. WPF, flop. Flex, flop. GTK+ looks poo. If I had to do a cross platform desktop app, I wouldn't even know where to start.
Dunno about cross-platform app development, but Cocoa on OSX is pretty nice. QT isn't bad either, from what I've tried.
> text display, scripting, styling
The only thing that really matters is scripting. Every serious editor has solved displaying text and styling since ages and those two points aren't even that important in programming languages. All you want is a syntax aware highlighting. Maybe underlines and a little bold here and there.
Scripting is the really hard part. There are many flavors, languages, APIs to chose from. Just because you now can script things in <hip-language-of-the-day>, the problem isn't solved. My editor uses a lisp dialect and I'm perfectly happy with it, not because of the language choice but the APIs and amount of integration.
One thing that is incredibly important for text editors is speed: something web engines are notoriously bad at.
"Every serious editor has solved displaying text and styling since ages ago..."
"...and those two points aren't even that important in programming languages."
"One thing that is incredibly important for text editors is speed: something web engines are notoriously bad at."
"So why is every text editor I have ever seen embedded in a website an abomination?"
Because most websites use contenteditable for their rich text editors, which is horrible to deal with. It's not standardized, it gives developers very little control, and its output and capabilities vary a lot from browser to browser.
Web rich text editors that don't suck - e.g. Google Docs - bypass the browser's support for rich text editing entirely. This makes them usable, but it also means everything has to be implemented from scratch, so the code is complex. AFAIK there are no general purpose rich text editors built like this that are open source or even licensable.
There are some pretty good non-contenteditable code editors, though. Presumably Atom will be built in this style.
I couldn't find mention anywhere about offline abilities.
Check out Brackets (http://brackets.io/) and Eclipse Orion (http://eclipse.org/orion/) who both have been trying to build fully open editing experiences. There are more out there but those come to mind.
Would be nice if more people started working together on these things...
I am a vim user, I recently learned a lot of power moves in SublimeText and this is my go-to editor now. Making me use anything else would be super difficult but not impossible. Price is not the issue.
Subatom seems like a great project title :)
I for one am more enticed by the possibility of a WebKit frontend, with a NeoVim core and a libuv backend. Finally, Vim as an embeddable library.
It is kinda cool, but holy shit is it slow. Editing a plugin requires a reload. A reload is a good 2-4 seconds on my 4 year old mbp.
The vim-mode is very incomplete and very buggy. Granted that should get a lot better in time.
https://gist.github.com/anonymous/9265315
Then visit the resulting link output by curl. You're welcome.
Would love to see some innovation on the Ruby editor front.
Looks like i was wrong.
(I really need a lobste.rs invite...)
Besides, for the tech purported to be behind Atom: node-webkit, There would be no additional costs or efforts required to get it running on Linux.
The moment that their new editor provides some piece of Github functionality that isn't exposed to an open API is the moment that we need to bail, en masse.
We've already killed Freshmeat and Sourceforge for turning lame, this shouldn't be hard.
Really, was anybody asking for all this?