Glancing at their screenshots...
...it looks like Sublime Text. Right down to the command palette thing they swiped from them.
Github has released a beta of what it says is “ the text editor we've always wanted.” Atom, for that is the software's name, is billed as “modern, approachable, and hackable to the core” and also “welcoming to an elementary school student on their first day learning to code, but also a tool they won't outgrow as they develop …
...it looks like Sublime Text. Right down to the command palette thing they swiped from them.
There's something oddly familiar about this. Will I be hearing "Chromium is a nice text editor, now all it needs is a browser"?
If notepad is sufficient for your – clearly limited by definition – text file editing needs, then stick with notepad.
For those of us who work with non-trivial text files, there are lots of options: this has a lot to live up to.
And yes, it does sound rather like that everything is programmable/customisable approach of Emacs and other editors that have survived for more than a few update cycles. This is no bad thing: just because it is an old (relatively) idea does not mean it is a bad idea (equally a new idea is not automatically a bad idea).
I too read this and immediately thought emacs. I then thought of Netscape Composer. Then I thought I really don't get that the editor needs to be a browser. Have they not thought of debuggers, where the code view and the application are presented independently but such that you can interact with both?
Perhaps if I wasn't using any tooling already I might pause to consider whether this would be useful. But I already have a bunch of excellent tools that do what I need (including git itself). Meh.
@richardcox13; Wheel, reinvented?
The combo does all the above, and more (with your output/display software of choice to test results, of course!). And has for a couple of decades, with far less overhead. Why do the kiddies keep trying to re-invent the wheel? (That's rhetorical ... Lack of education in the basics is an ugly thing.)
EMACS works similarly, if you like software bloat.
It's probably something to do with how both vi and emacs are old, unpleasant, user hostile programs used as a masochistic rites of passage by wannabe UNIX nerds.
If I need to prove how big my cock is, I'll get it out of the night stand and bludgeon you round the head with it. For everything else, I'll use sublime text and actually get some work done.
Such hostility (you may have issues that would be better addressed elsewhere ...). But thank you for underlining my point that lack of education in the basics is an ugly thing.
"It's probably something to do with how both vi and emacs are old, unpleasant, user hostile programs used as a masochistic rites of passage by wannabe UNIX nerds."
"Old", certainly. But not as unpleasant or hostile as your average CSS "programmer", apparently.
vi blah blah blah emacs crap blah blah blah. Hark at the spotty brat spouting the old cliches to try to sound like a veteran ...
The choice of editor is a very personal thing. Personally, I've never got on with vi's way of doing things but I know people who love it because of the way it works. Great if it works for you.
Wouldn't know, I write RTOSen for a living. Rarely surface long enough to deal with users.
> Why do the kiddies keep trying to re-invent the wheel?
Why do you have to be such a dick? Howsabout being not-a-dick for a refreshing change?
How about reading for content instead of casting aspersions?
Obviously. Learning about what you comment on is kinda important.
vi is rather good. Actually, I like it more and more as the years pass and I try others, usually trying to show me they know what I want to do better than I do.
To the "writer" who is so rude about old and ugly editors, I would point out that vi and emacs (not that I much like the latter) were used to produce the source code and documentation of UNIX, X11 and so much more. They still are remarkably popular and vi (with its links to ed and ex) are still part of the basic distribution of UNIX and Linux, being useable even when the point and click interfaces are not yet running.
Sed, ed and ex are brilliant for automating editing in shell script or on the command line. I suspect almost none of the latest generation of editors can do that.
An editor should be light weight, useable without my fingers having to dance around the keyboard and my eyes away from the screen (being one who can touch type and hate having to leave the basic position to find some odd combination of keys/arrows/page-up ….). It should be fast and not require a different configuration for every language or document and definitely not require network connectivity to use it.
Most users, even frequent vi users, miss some of the neatest and simplest facilities, such as map, abbrev, macros. Most wysiwyg editors seem to provide very limited ability to do interesting changes in one hit across a whole file and certainly not without needing a full, windowing environment.
But then, I remember when Teco was thought to be rather fine (which it was - claimed by some to be a philosophy rather than an editor).
It's curious that, as editors change, even being dressed up in Eclipse and the like, the quality of the code or documents produced seems no better, perhaps even worse. And that's another thing: having to use different tools to produce even simple documents or a simple text file (same gripe there against Git and its ilk, that seem to assume that no project includes documentation, imported, compiled libraries, release kits etc. that should be under the same version control as the raw source.)
How about writing content instead of being a dick? Self-regarding snark is not informative.
(Heavy emacs user FWIW)
"(Heavy emacs user FWIW)"
Ah. Religion vs technology.
I know EMACS well. Every time you use it, you are (probably) using code I contributed over the years. My point is that I like using fewer system resources to do the same job, with a smaller learning curve. Especially when I'm teaching. EMACS is over-kill for damn near everything.
Walk softly, but carry a big stick. Take nothing but pictures, leave only footprints.
No, I'm not a hippy.
> Ah. Religion vs technology.
The 'FWIW' was a hint that IMO one's editor is a matter of choice not religion. Esp. a hint that I didn't want to get into a vi vs emacs religious war.
> Every time you use it, you are (probably) using code I contributed over the years.
Mmm. Among your other significant contribs, I imagine, like BSD networking IIRC. Care to point to said emacs commits?
It's not April yet is it?
Also, get off my lawn!
We need a new editor to keep up with Moore's Law in the 21st century, as EMACS has clearly fallen behind.
I think Canonical is working on that. Anything to be better than Redmond or Cupertino.
Sorry don't get that. Are thy making it swap more or less?
Redmond in particular are known for their bloatware and Cupertino for not not doing anything that doesn't look absolutely perfect (even though it only works if you hold it right).
Anything that doesn't look perfect? Seriously, go look at iTunes. Pretend you haven't seen it before, and someone's sent you a link to some perfect-looking software.
Disappointing, isn't it :)
The more we forget the past, the more we are doomed to repeat it.
And this is different from Caret how, exactly? (which, according to the blurb, was motivated by the desire to have something like Sublime/TextMate which ran on a Chromebook)
(despite having used vi/vim in various incarnations since I was at university in the late 80s, Caret isn't actually too bad for a 'graphical' editor)
I'll continue to use gvim.
This won't be better.
OK MS might make IE too difficult to work with but just make a standards compliant one and let then learn.
Why not write it as a Chrome app instead of needing a dedicated browser just for the editor? The Chrome APIs allow local filesystem access, etc.
Indeed it does - and this is exactly what Caret is; a text editor which runs as a Chrome app. All of which makes me wonder why GitHub decided to replicate the functionality in an arse-backwards fashion. Indeed, given that Other Chrome-Based Text Editors Are Available[tm] it makes me wonder why they bothered at all.
(note that I have no vested interest in the development of said editor, but I do use it a fair bit on my Chromebook if I need to do some quick-and-dirty editing that doesn't warrant firing up a crouton chroot jail)
> All of which makes me wonder why GitHub decided to replicate the functionality
Because they like doing that sort of thing? Make yet another version of something that already exists, not quite the same as anyone else's... like "Github-Flavored Markdown". At least if they'd perservered with the Sundown library then us smaller projects could keep up, but switching from a nice simple C library to re-implementing it in Ruby makes it far harder to re-use GFM. The Markdown Fragmentation continues.
(Yes, I know that all happened a while back, I'm just slow updating libraries...)
Because that would require Chrome which is the new IE6 with its disregard for standards and it's "Chrome Apps" for ActiveX.
Over the years I've used a wide variety of editors, from edlin to <insert name of favourite powerful editor here>, to write code and munge data.
I've found much to criticise and wish for in most of them. Oddly enough, the one thing I've never thought is "I wish this editor was part of, or an offshoot from, a web browser". It's impressive that they can do it, but I find it hard to imagine why they want to.
I guess it gets you rich text with an established scripting language and platform-neutral API which doesn't enforce many assumptions about specific typography?
Though I'm not very enthused if the first laundry list item is a "file system browser". My OS already has one of those. Yours does too. They're probably different. Why would either of us want to learn a third?
Just use whatever's already in the OS, please. I don't care how boring it is.
"Every Atom window is essentially a locally-rendered web page"
The '80s called and Sun wants their idea back.
Surprised at the responses here, haven't you guys ever heard of adapting the tool to the user, not the user adapting to the tools? This is just taking that concept one step further; every aspect of the application can be reviewed and changed by the community with relative ease.
Are you seriously saying that you wouldn't change a single detail of vi, given the chance? That question is rhetorical, I wouldn't believe you if you said no.
Unrelated note, the GIT integration looks damned handy.
Adapting the tool to the user only works on a personal level (and i heartily approve of this, in certain situations!).
But we are discussing low-level software tools from a meta perspective.
If every wrench had a differently sized set of sockets, the world would never get any work done.
My version of vi has tweaks that would make your hair curl (or straighten, depending) ... but if you know vi (and the password), you can still log on to this machine & edit code ... Standards exist for a reason.
Biting the hand that feeds IT © 1998–2017