Github brews text editor for developers 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 …
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.
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.
"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 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.)
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.
What this thing seems to have going for it is the ability to use the internal JS runtime for working, presumably primarily with Node.js, with Javascript. And previewing generated content. That might make debugging a little easier.
"(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?
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)
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...)
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
