271–280 of 662 posts
> 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.
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…
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.
Earlier quoted context omitted.
Any chance for ChromeOS support?
It's most likely not possible until there's a "hosted atom" you connect to with your browser. ChromeOS is /just/ a web browser and won't run node, which Atom uses to do its processing.
A common thread or line of argument that I find when reading about new editors is their out-of-the-box ease of use compared to Emacs and Vim. For example, a quote from the Atom blog: >Sublime and TextMate offer convenience but only limited extensibility. On the other end of the spectrum, Emacs and Vim offer extreme flexibility, but they aren't very approachable and can only be customized with special-purpose scriptin…
This ludditic reverence for user-hostile text editors is one of the more perplexing and frustrating things about our industry.
Earlier quoted context omitted.
> 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.…
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…
Earlier quoted context omitted.
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.
check out lighttable [ http://www.chris-granger.com/2014/01/07/light-table-is-open-... ]
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 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 gaine…
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 al…
this looks fantastic! i've been wanting a reason to pick up a cheap chromebook.
lol , since when ChromeOs can run desktop apps?