Moving Atom to React(blog.atom.io)
blog.atom.io
Moving Atom to React
http://blog.atom.io/2014/07/02/moving-atom-to-react.html
141 comments
I've used React since it became available and the editor is still pretty slow, to be honest. Can't imagine using it with the option enabled. Honestly, Sublime Text is great, I've purchased a license, but the speed of development will kill it. Every day I "Check Update" and I get disappointed. Not that it needs that much new stuff, but still. You don't feel the heartbeat, if you see what I mean. One great feature of Sublime that I miss in Atom is persisting unsaved changes between restarts, which I abused for temporary To Do lists and stuff.
Upon downloading and running Atom, that was also immediately the thing I missed most. I really love the scratch-space as a feature that Sublime Text gives me, and I find that I want it in more and more things.
This just shows how hard it is to please everyone - when I was using ST, disabling the open file persistence was the first thing I did. My usual workflow has me editing / looking up information in many different files, usually just a bit here and there, so at least once every two hours I'd cmd-q the whole mess and `e .` in the project directory and re-open the files as I need them.
Learn to use emacs! What's great about it is that it's so flexible and powerful that any one can make it please them. Pretty much every feature that ever shows up in a cool new editor I end up seeing in emacs too.
Very powerful editor (vim too), seriously consider challenging your assumptions around text editor productivity...
Also, use The Silver Surfer for finding stuff in files + [e,c]tags. Emacs has some nice modes for interfacing with those tools too :)
Very powerful editor (vim too), seriously consider challenging your assumptions around text editor productivity...
Also, use The Silver Surfer for finding stuff in files + [e,c]tags. Emacs has some nice modes for interfacing with those tools too :)
I think it just shows that you do computers wrong.
Okay sorry that sounds snarky and unproductive- What I mean is, as a model for how human evolved navigation works- a persistant work space with effectively no need to "save" work is more like reality. If you scribble something on a napkin, and leave it on your desk, the desk doesn't demand you name the napkin when you try to leave the house. At the exact moment you need to leave to go to work, is the exact moment you are least prepared to think of a name and location to find something later.
But with a persistent workspace, you can just shut the program instantly, without being spammed by 15 "save, discard, cancel" dialogues. Pressing the power button on the computer, and having the computer just.. turn off… and then turn back on having not forgotten anything by accident or otherwise. You can name and save stuff AT YOUR LEISURE.
that. is. the. future.
…. of 1996. It's 2014 now and we've just now gotten round to adding it… to one program. a text editor. now we just need to get the rest of the developers in the world on board with this really obviously correct thing to do.
Okay sorry that sounds snarky and unproductive- What I mean is, as a model for how human evolved navigation works- a persistant work space with effectively no need to "save" work is more like reality. If you scribble something on a napkin, and leave it on your desk, the desk doesn't demand you name the napkin when you try to leave the house. At the exact moment you need to leave to go to work, is the exact moment you are least prepared to think of a name and location to find something later.
But with a persistent workspace, you can just shut the program instantly, without being spammed by 15 "save, discard, cancel" dialogues. Pressing the power button on the computer, and having the computer just.. turn off… and then turn back on having not forgotten anything by accident or otherwise. You can name and save stuff AT YOUR LEISURE.
that. is. the. future.
…. of 1996. It's 2014 now and we've just now gotten round to adding it… to one program. a text editor. now we just need to get the rest of the developers in the world on board with this really obviously correct thing to do.
> If you scribble something on a napkin, and leave it on your desk, the desk doesn't demand you name the napkin when you try to leave the house
Maybe if they did, my desk wouldn't be so untidy right now.
The save/discard/cancel dialogs are there for a reason: the computer doesn't know whether you want to save or discard! "Keep everything" is not a solution.
Usually I will keep about 50% of the "unattached" files I create. Some will be good ideas: they get saved. Some will be go nowhere: I throw those away.
For files attached to a project it's more like 100% -- so they should be named upfront on creation.
Besides, doing something "at your leisure" is a euphemism for never doing it at all. People are difficult like that.
Maybe if they did, my desk wouldn't be so untidy right now.
The save/discard/cancel dialogs are there for a reason: the computer doesn't know whether you want to save or discard! "Keep everything" is not a solution.
Usually I will keep about 50% of the "unattached" files I create. Some will be good ideas: they get saved. Some will be go nowhere: I throw those away.
For files attached to a project it's more like 100% -- so they should be named upfront on creation.
Besides, doing something "at your leisure" is a euphemism for never doing it at all. People are difficult like that.
so when you're trying to do something else is the time to be making these decisions?
On the bright side, if memristors work the way I think they do, by 2030 you should be able to shut down any computer and turn it on in to precisely the same state as it was before, even if things are in mid-computation.
I have this feature I really like in Windows, Linux and Mac OS X that's called "hibernate". It basically works like you described :-)
(Expecting explanation on why hibernation is considered harmful. )
(Expecting explanation on why hibernation is considered harmful. )
Is there an argument that hibernate is harmful? I hadn't heard that one.
It's certainly useful, but I think the comment you were replying to was thinking more along the lines of saving that state without doing all the work our computers have to do to go into hibernate.
I for one would love a faster and less error prone sleep/hibernate feature. (Although recent Mac OS implementations have really cut down on the error prone part of that. I'm not sure where the Linux/Windows crowd is on that, I would assume the story is the same/similar.)
It's certainly useful, but I think the comment you were replying to was thinking more along the lines of saving that state without doing all the work our computers have to do to go into hibernate.
I for one would love a faster and less error prone sleep/hibernate feature. (Although recent Mac OS implementations have really cut down on the error prone part of that. I'm not sure where the Linux/Windows crowd is on that, I would assume the story is the same/similar.)
OS X has also really cut down on the time it takes as well. I close my Macbook Air, and the lights cut off instantly. I open it up, and in the time it takes me to type in my password, it's loaded itself to the exact state I left it in (actually did it while typing this comment). I haven't used a Windows or Linux laptop in a while, but I hope for the sake of people that have, that it's a similar experience. Having the freedom to close your laptop without a second thought is great.
actually, several programs of the OSX stack behaves like this, take the Notes app for example
Yeah, since this is generally how things work in OS X it makes Atom feel quite ancient to me.
It's such a major step in the wrong direction to have to go back to trying to avoid shutting down applications/your computer since it's such a big hassle.
If I want save something I'll save it and if I want to close something I'll close it, just keep it "open" for me in the mean time.
It's such a major step in the wrong direction to have to go back to trying to avoid shutting down applications/your computer since it's such a big hassle.
If I want save something I'll save it and if I want to close something I'll close it, just keep it "open" for me in the mean time.
Atom persist the workspace per directory.
$ atom some/where/to/my/project
# open files
# close atom
$ atom some/where/to/my/project
# atom reopens everything I had open for that project
It's not really the same thing, but there's a scratchpad plugin for Atom that might be useful for you.
https://atom.io/packages/scratchpad
https://atom.io/packages/scratchpad
I too feel this way, it seems to still have that signature javascript 'lag' where ST3 is very snappy, also it still can't load files > 2MB.
I like that core Sublime Text is stable and fast. Where 'interesting' things mostly happen in the thousands of available plugins.
Speed, good core API design, and stability take time.
Speed, good core API design, and stability take time.
Use emacs and melpa and you'll really feel the thrill of constant updates.
Having spent the past two weeks diving deeply into React, this doesn't surprise me. If you haven't tried it out, give it a go.
Being able to rewrite the virtual DOM at will makes development so much cleaner, and it plays incredibly well with other tools, because React is just a presentation layer (I'm using it with Backbone)
There are rough edges (TransitionGroup), but they clearly know what they are doing.
Being able to rewrite the virtual DOM at will makes development so much cleaner, and it plays incredibly well with other tools, because React is just a presentation layer (I'm using it with Backbone)
There are rough edges (TransitionGroup), but they clearly know what they are doing.
TransitionGroup also annoys me to death. If you have any thoughts on animation please chime in here:
https://groups.google.com/forum/#!topic/reactjs/2-RhZTHxNdc
But yeah, I agree -- development is massively cleaner in nearly every single way.
https://groups.google.com/forum/#!topic/reactjs/2-RhZTHxNdc
But yeah, I agree -- development is massively cleaner in nearly every single way.
Do you have an example where you rewrite the virtual DOM? I don't see anything like that on the React site.
I assume they're just referring to how React works under the hood - you just change the data and that cascades down through the components rewriting (ie. changing) only the parts of the virtual DOM that changing, which then get applied to the real DOM.
Can this play nicely with Angular and still make use of Angular's two-way binding?
I think its important to note that React does not encourage two way data binding. Quite the opposite, actually. Data is supposed to flow one-way, from parent to child.
That being said, there's an extension that adds two way bindings, called ReactLink. You can read more about it here: http://facebook.github.io/react/docs/two-way-binding-helpers...
That being said, there's an extension that adds two way bindings, called ReactLink. You can read more about it here: http://facebook.github.io/react/docs/two-way-binding-helpers...
Take a look at http://josebalius.github.io/ngReactGrid/ for an example.
I'm not an expert but I think you wouldn't really want to do this as they both want sole control of the chunk of DOM in question.
Look at some of Peter Hunt videos:
https://facebook.github.io/react/docs/videos.html
2-way binding is not necessarily the way to go with this.
https://facebook.github.io/react/docs/videos.html
2-way binding is not necessarily the way to go with this.
good~
Yes, and apparently you can take advantage of React's faster/smarter rendering (http://www.williambrownstreet.net/blog/2014/04/faster-angula...)
That said, I would be uncomfortable mixing something as opinionated as Angular with another framework that expects to "own" the DOM/rendering. My guess is that Angular will implement their own version of VDOM in the next few months since it shows demonstrably better performance.
That said, I would be uncomfortable mixing something as opinionated as Angular with another framework that expects to "own" the DOM/rendering. My guess is that Angular will implement their own version of VDOM in the next few months since it shows demonstrably better performance.
Pretty much this. AngularJS abstracts DOM manipulation away from the user; by adding React to an AngularJS project, you're giving up on that abstraction. I consider React a sacrifice of abstraction / ease of development in favor of performance.
I think AngularJS will adopt a similar strategy for their 2.0 development effort, maybe even a 1.x point release. But I haven't looked at the angular development process for a while now.
I think AngularJS will adopt a similar strategy for their 2.0 development effort, maybe even a 1.x point release. But I haven't looked at the angular development process for a while now.
I disagree with this. React abstracts away DOM manipulation just as well as Angular does at a high level. When you dive deeper (i.e. building components/directives) React continues to abstract it away, whereas Angular reveals it.
In fact, React is able to get superior performance because the DOM is abstracted so far away.
In fact, React is able to get superior performance because the DOM is abstracted so far away.
if all you're after is two-way data binding and don't necessarily need all the other functionality provided by Angular, it might be worth mentioning that React actually can do that, even though it's not a pattern that occurs that often if you use the Flux application architecture
http://facebook.github.io/react/docs/two-way-binding-helpers...
http://facebook.github.io/react/docs/two-way-binding-helpers...
I'm interested in this as well. I believe some people have had success by attaching components to the window as globals.
So psyched. The speed in which the editor used to function drove me totally crazy and I was hoping that GitHub would find a solution. And I'm doubly psyched that they chose such an awesome technology! Great work.
edit: Just installed the update and indeed, all of the "clunk" that you used to feel is gone. Gonna retire Sublime Text 3 now :)
edit: Just installed the update and indeed, all of the "clunk" that you used to feel is gone. Gonna retire Sublime Text 3 now :)
I don't know if I'm ready for that step yet.
One thing that attracts me to Atom is the infinite UI hackability. If I don't like the color of the text in the tree view, I can change that, just by writing CSS. It's an editor by the web, for the web, and of the web.
Sublime, however, feels much more fluid. When I open a file in the tree view, it animates down (have yet to get that working properly with Atom - it animates but it looks choppy). It's faster, for obvious reasons. The themes I have in place look damn good, and I have a git package that can show me a diff of the file I'm looking at (oddly, Atom lacks this feature).
I very much look forward to following Atom and maybe in a year or two, if they've gotten it up to a level of performance I can tolerate, I'll give it another shot.
Ultimately, right now the choice is between the performance and usability of Sublime, vs the aesthetics of Atom. Sublime's performance actually gives it a bit of an aesthetic edge over Atom, so despite the hackability of Atom's UI, it's just not there... yet.
I'd love to make the switch, but the subtle (though perceptible) UI lags and smaller ecosystem make it a subpar choice right now.
One thing that attracts me to Atom is the infinite UI hackability. If I don't like the color of the text in the tree view, I can change that, just by writing CSS. It's an editor by the web, for the web, and of the web.
Sublime, however, feels much more fluid. When I open a file in the tree view, it animates down (have yet to get that working properly with Atom - it animates but it looks choppy). It's faster, for obvious reasons. The themes I have in place look damn good, and I have a git package that can show me a diff of the file I'm looking at (oddly, Atom lacks this feature).
I very much look forward to following Atom and maybe in a year or two, if they've gotten it up to a level of performance I can tolerate, I'll give it another shot.
Ultimately, right now the choice is between the performance and usability of Sublime, vs the aesthetics of Atom. Sublime's performance actually gives it a bit of an aesthetic edge over Atom, so despite the hackability of Atom's UI, it's just not there... yet.
I'd love to make the switch, but the subtle (though perceptible) UI lags and smaller ecosystem make it a subpar choice right now.
There is a git-diff package that shows colored bars next to the line numbers: https://github.com/atom/git-diff. While not a real diff I find it pretty helpful.
Yeah, I do have that installed. It's nice to know how big of a change I made, but still requires me to use more memory than I'd like when composing a commit (or go to the terminal).
Maybe SublimeGit has spoiled me, but I really feel like leaving my editor to make a one-file commit is for the birds. It doesn't break my workflow nearly as much as popping back to the terminal, doing a status to make sure I'm committing what I think I am, adding the file, then doing a commit, then (possibly) pushing. 3-4 steps compared to 1 from the editor (add and commit, or add and commit and push, this file).
Maybe SublimeGit has spoiled me, but I really feel like leaving my editor to make a one-file commit is for the birds. It doesn't break my workflow nearly as much as popping back to the terminal, doing a status to make sure I'm committing what I think I am, adding the file, then doing a commit, then (possibly) pushing. 3-4 steps compared to 1 from the editor (add and commit, or add and commit and push, this file).
I hope that some day Atom is fast, full of features, and on Windows. My gut tells me it will be a long, long time til it replaces Sublime Text 3 as my editor of choice. =[
Edit: Since several people chimed in with the same thing. I'll check out the windows binaries for. I expect to use ST3 for awhile longer still, at least until Windows is a first class citizen, but this will be great to monitor Atom's development. Thanks!
Edit: Since several people chimed in with the same thing. I'll check out the windows binaries for. I expect to use ST3 for awhile longer still, at least until Windows is a first class citizen, but this will be great to monitor Atom's development. Thanks!
It's already got a huge amount of features when you include packages (and installing them is completely frictionless). Unofficial windows builds exist too[1]. And as someone who's used to heavyweight IDEs, Atom is already pretty fast (not that I'm going to complain about the react update...)
[1] http://atom.someguy123.com/
[1] http://atom.someguy123.com/
Prebuilt windows downloads: http://atom.someguy123.com/
You can install it on Windows. You just have to build it yourself.
https://github.com/atom/atom/blob/master/docs/build-instruct...
https://github.com/atom/atom/blob/master/docs/build-instruct...
The pre-built binaries are OSX only but there are instructions for building on Windows and Linux.
The new rendering method kills subpixel font rendering, I suspect due to the translate3d hardware acceleration. Unfortunately noticeable for those of us not yet on retina-resolution screens.
The font rendering in Atom is what's currently keeping me from giving it a serious try:
http://discuss.atom.io/t/atom-vs-textmate-font-rendering/907...
http://discuss.atom.io/t/atom-vs-textmate-font-rendering/907...
You can disable hardware acceleration in the React editor in the settings view to get subpixel anti-aliasing back at the cost of performance. A frustrating trade-off for us, to be sure.
So it's a change for the worse in other words.
Yeah, I was wondering what was wrong.
So it's a change for the worse in other words. This should be the top voted comment.
This is a natural consequence of forcing an editor into the browser. Everything about Atom just seems so unneccessary to me.
What's compelling about Atom that draws people in, compared to Sublime or even vim (my editor of choice)?
What's compelling about Atom that draws people in, compared to Sublime or even vim (my editor of choice)?
> compared to Sublime
It's open source; Sublime isn't. I can't do anything to make Sublime better.
It's open source; Sublime isn't. I can't do anything to make Sublime better.
Except for writing plugins in a way that seems to be tacked on at the end - whereas atom's packages are at the core of the editor.
It's very easy to make plugins for. Most web developers know JavaScript, not everyone knows vimscript/viml
To be fair you can write vim plugins in python, and a fair number of people do.
It's also, I'd argue, a fail from the Atom guys to make their plugins run in coffee script natively, rather than allowing people the choice of compile-to-javascript/native javascript to write plugins in (this has definitely hurt adoption for the creation of plugins that do more than trivial things or syntax highlighting).
The thing about atom that is compelling for me is apm (the command line atom package manager); its really very good.
(Yes, I know you can write 'pure javascript' atom plugins, but its complex and it's clunky; you have to manually implement the coffee script inheritance semantics. Fail.)
It's also, I'd argue, a fail from the Atom guys to make their plugins run in coffee script natively, rather than allowing people the choice of compile-to-javascript/native javascript to write plugins in (this has definitely hurt adoption for the creation of plugins that do more than trivial things or syntax highlighting).
The thing about atom that is compelling for me is apm (the command line atom package manager); its really very good.
(Yes, I know you can write 'pure javascript' atom plugins, but its complex and it's clunky; you have to manually implement the coffee script inheritance semantics. Fail.)
"Coffeescript inheritance semantics" aren't anything special in javascript. If the editor was written in javascript syntax and still chose to make use of inheritance in its design, extensions would look the same.
This works just fine, and it can't get much more javascripty:
This works just fine, and it can't get much more javascripty:
ExtensionComponent.prototype = Object.create(Component.prototype);
function ExtensionComponent() {
Component.call(this);
}
ExtensionComponent.prototype.doSomething = function () {
// ...
};Have you actually tried it?
Seems like the people who actually have found it a little more complicated than that (see http://discuss.atom.io/t/coffeescript---extends-vs-util-inhe...).
To quote the post:
Seems like the people who actually have found it a little more complicated than that (see http://discuss.atom.io/t/coffeescript---extends-vs-util-inhe...).
To quote the post:
The difference is important. CS copies functions from parent to child on top of
setting the prototype while the std library just does the latter. Inheriting from
require("atom").View breaks without doing this manually (which isn't obvious at all).
If this is not being done for performance, it should be documented; otherwise, those
methods should be moved to the prototype.You can write plugins for vim in python, perl and ruby aswell.
I've been using Atom for a while now, and I'm really impressed with the progress that it's showing. There are still some times that I'm forced to switch back to Sublime (mass-editing a large text file for instance), but I'm really enjoying the experience!
A 2 MB file limit makes Atom just impossible for me to use.
I just opened a 131-meg file in TextMate 2 to see what would happen. It was very slow, but perfectly possible.
In particular, loading the file into TextMate took about 15 sec. Searching for a string (using ^S) took 2 or 3 sec per occurrence (i.e., per tap of the S key with the control key held down). Inserting took 2 or 3 seconds per character. Scrolling was probably just as snappy as it is in a small file. In particular, by dragging in the scroll bar a person can smoothly scroll past many megs of text per second.
In GNU Emacs, loading took about 4 sec, after which scrolling, searching, moving to the top or bottom, and inserting (even near the end of the file) were instantaneous.
In particular, loading the file into TextMate took about 15 sec. Searching for a string (using ^S) took 2 or 3 sec per occurrence (i.e., per tap of the S key with the control key held down). Inserting took 2 or 3 seconds per character. Scrolling was probably just as snappy as it is in a small file. In particular, by dragging in the scroll bar a person can smoothly scroll past many megs of text per second.
In GNU Emacs, loading took about 4 sec, after which scrolling, searching, moving to the top or bottom, and inserting (even near the end of the file) were instantaneous.
Curious: what type of things would you want to edit over 2MiB? I think it's probably more a function of "having such a huge DOM would be a bad UX anyway" vs just some arbitrary limit.
Log files.
I'm curious, do you really need a text editor for log files? It seems like the wrong tool, after all, you're not editing your logs. I have never found a case where `cat example.log | grep Error | less` is insufficient.
Granted, I think a good editor should be able to handle files of any size, but if atom sacrifices that for the ability to let an extension display anything it wants inline with the text, it doesn't seem like a catastrophic loss.
Granted, I think a good editor should be able to handle files of any size, but if atom sacrifices that for the ability to let an extension display anything it wants inline with the text, it doesn't seem like a catastrophic loss.
I use grep every day, but never from a terminal emulator or from an interactive Unix shell. (I use Emacs's grep mode.)
And almost never without visiting (opening in the editor) at least one of the files being grepped.
And almost never without visiting (opening in the editor) at least one of the files being grepped.
Moreover, if you really need a text editor for a log file, you can just launch vim or something for that task.
I've never really understood why people get in this mindset of "X is my editor, and I will only use X."
I guess, though, this is harder to do if you insist on a completely GUI-based interface.
I've never really understood why people get in this mindset of "X is my editor, and I will only use X."
I guess, though, this is harder to do if you insist on a completely GUI-based interface.
> I've never really understood why people get in this mindset of "X is my editor, and I will only use X."
If you use certain software a lot, you'd find it behaviour and shortcuts ingrained into your subconscious mind. Like driving: an experienced driver doesn't consciously think of how to control the car, she just does.
This is what makes Emacs or vi users so efficient: they had years to get the operation of those editors ingrained into their brains. Which takes quite an effort, that is not worth repeating with another editor (unless yours is broken).
If you use certain software a lot, you'd find it behaviour and shortcuts ingrained into your subconscious mind. Like driving: an experienced driver doesn't consciously think of how to control the car, she just does.
This is what makes Emacs or vi users so efficient: they had years to get the operation of those editors ingrained into their brains. Which takes quite an effort, that is not worth repeating with another editor (unless yours is broken).
There's no reason to downvote me because you have a different opinion. I thought this place was supposed to be better for discussion but evidently not.
I'm a vim user who can easily use something else if it's better for a certain purpose. I guess not everybody feels the same way and some are even offended by the suggestion.
I'm a vim user who can easily use something else if it's better for a certain purpose. I guess not everybody feels the same way and some are even offended by the suggestion.
The offense is not about not agreeing with you it seems but about the way you present it. (Disclaimer: not a downvoter, just an observer. )
[deleted]
> I'm curious, do you really need a text editor for log files?
Well, it doesn't always boil down to "grep for one specific thing." Usually you find one thing, then you have to locate the next couple instances of it (I use vim, so I'm used to just doing nnnnnnnn... to keep finding the next occurrence). Or perhaps you grep for one specific thing, find out something is related, need to search for some other thing, etc. Maybe you need a little bit of context around the thing you grepped for. Text editors work pretty well for combing through log files...
Well, it doesn't always boil down to "grep for one specific thing." Usually you find one thing, then you have to locate the next couple instances of it (I use vim, so I'm used to just doing nnnnnnnn... to keep finding the next occurrence). Or perhaps you grep for one specific thing, find out something is related, need to search for some other thing, etc. Maybe you need a little bit of context around the thing you grepped for. Text editors work pretty well for combing through log files...
I regularly work with 70MB-150MB csv files that need editing in a few places before being imported to the db.
Not trying to start an editor war, but I've been trying to learn Emacs for the past week. The learning curve is still at the point of being frustrating/painful. Should I stick with it or download Atom? (Anyone have a solid opinion between the two?)
You probably do want an editor that is free, can be used for the rest of your life, works perfectly in a terminal, and is completely programmable.
I suggest you continue on with your ascent to emacs understanding! Be sure to use something like prelude, i.e. something with 'sane defaults', and checkout this slideshow by emacs enthusiast (and chief designer of ruby) Yukihiro Matsumoto. (http://www.slideshare.net/yukihiro_matz/how-emacs-changed-my...)
It took me 3 weeks to become proficient, and I moved from Sublime Text 2.
I suggest you continue on with your ascent to emacs understanding! Be sure to use something like prelude, i.e. something with 'sane defaults', and checkout this slideshow by emacs enthusiast (and chief designer of ruby) Yukihiro Matsumoto. (http://www.slideshare.net/yukihiro_matz/how-emacs-changed-my...)
It took me 3 weeks to become proficient, and I moved from Sublime Text 2.
I'll check out Prelude; I have better-defaults installed, but this seems to be much more radical. Just curious, how did you find out about Prelude? I'm a freelancer so I don't have any in-person exposure to model/mentor programmers outside of the web, and I'm thus finding it difficult to even know if I'm using Emacs in a sane way. For example of the type of things I wonder about: do most Emacs users keep the basic keymapping the same (C-n, C-p, C-f, C-b etc.) or do many switch to a non-conflicting but more ergonomic alternative. (The idea that such an important keymapping is decided by the first letter of an action rather than ergonomic sensibility is insane to me.)
Almost every Emacs user uses the standard keybindings for most stuff (though many change the odd binding or two for personal reasons). They work really well once you get used to them, and they tend to form a system: C-f goes forward a character, M-f goes forward a word, C-M-f goes forward an "expression", and those same modifier keys have similar relationships for other commands.
As for ergonomics... Emacs bindings feel far more natural and comfortable than any other editor bindings I've ever used, but then I've used Emacs for a long time and am well used to them. I suspect that the same is true for most people: what feels/works best will have more to with what you're used to than any inherent superiority. [And probably no keyboard-oriented editor that's been successful for any length of time will have a truly un-ergonomic design, because it couldn't have succeeded with such.]
Probably the closest thing to what you're describing is the various editor emulation packages, which often remap many basic bindings... Of these, vi/vim emulation is probably the most popular these days, and there are like 4-5 vi/vim emulation packages, of varying degrees of sophistication (and age), although I'm not sure which is the current favorite (maybe "evil"? http://www.emacswiki.org/emacs/Evil ).
As for ergonomics... Emacs bindings feel far more natural and comfortable than any other editor bindings I've ever used, but then I've used Emacs for a long time and am well used to them. I suspect that the same is true for most people: what feels/works best will have more to with what you're used to than any inherent superiority. [And probably no keyboard-oriented editor that's been successful for any length of time will have a truly un-ergonomic design, because it couldn't have succeeded with such.]
Probably the closest thing to what you're describing is the various editor emulation packages, which often remap many basic bindings... Of these, vi/vim emulation is probably the most popular these days, and there are like 4-5 vi/vim emulation packages, of varying degrees of sophistication (and age), although I'm not sure which is the current favorite (maybe "evil"? http://www.emacswiki.org/emacs/Evil ).
also don't forget to take a look at technomancy's emacs starter kit, which was very helpful to me when I got started using emacs:
https://github.com/technomancy/emacs-starter-kit
https://github.com/technomancy/emacs-starter-kit
I use ST because it just works.
Let me tell you.. Atom will probably never come
close to Emacs programmability and extensibility.
Its by far the most beautiful software
environment. Its a living thing.
In Emacs you're constantly reminded of the love of
generations of hackers in improving it. The
C-core-and-Lisp-scripting pattern was a perfect
match. Emacs has the quality without a name.
But Atom is modern. Emacs is single threaded (IIRC)
and a single evil elisp snippet takes it to its knees.
Those thousands of elisp mdoules (mostly) work together,
without any kind of sandboxing. I think this is also
notable and beautiful. It was achieved by a lot of
hackers who cared a lot.
erik naggum (rip, most people hated him, but he loved
and understood lisp and I want back to old usenet
posts for insights many times
those insights now lost somewhere)
luke gorrie (slime originator iiuc, mind blown w/ his demos.
also erlang guy and hacker at heart
steve yegge (js2, explained emacs qwan in many posts)
sacha chua
TamasPatrovics (anything!)
Eduardo Ochs (eev, built his own little world inside emacs)
David O'Toole (linkd.el, many other intersting packages)
rubikitch (!!! so many useful emacswiki snippets)
alex schroeder (emacswiki master iirc)
Matsushita Akihisa (moccur-edit.el, still miss this in Sublime)
dr qubit
Nikolaj Schumacher (beautiful auto completion packages)
xahlee
magnars sveen
Once I wrote an add-on to rcirc, the second emacs irc client. One guy tried and liked it. That made me very, very happy.
This was my only contribution to open source and I wish someday I can feel useful in that way again.
This was my only contribution to open source and I wish someday I can feel useful in that way again.
Unless you have a specific reason not to, you definitely should look at vi if you find Emacs' learning curve frustrating. Adhering to the Unix philosophy, vi lets you combine simple commands to achieve more complex goals, which makes the learning curve way more pleasant. For example, if you know how to jump to the next occurence of character x (fx), you already know how to delete from cursor to character x (dfx).
Vim is a very feature-rich editor, which can be distracting while learning the more basic steps. I started with nvi (the vi clone that ships with OpenBSD). Used copys of the 6th edition of O'Reilly's "Learning the vi Editor" (1998) are available practically for free. You don't have to read every single sentence ("remember that you must press ENTER to tell Unix that you are finished issuing your command"), but I found the structure very sensible.
If you don't think distraction is a problem for you, start with Vim and try the vimtutor.
Vim is a very feature-rich editor, which can be distracting while learning the more basic steps. I started with nvi (the vi clone that ships with OpenBSD). Used copys of the 6th edition of O'Reilly's "Learning the vi Editor" (1998) are available practically for free. You don't have to read every single sentence ("remember that you must press ENTER to tell Unix that you are finished issuing your command"), but I found the structure very sensible.
If you don't think distraction is a problem for you, start with Vim and try the vimtutor.
I tried and it didn't make sense to me. Having to switch modes is silly to me.
> For example, if you know how to jump to the next occurence of character x (fx), you already know how to delete from cursor to character x (dfx).
Yes but if I have to start typing I have to press some key to switch modes (i?). That is a no-go for me.
> For example, if you know how to jump to the next occurence of character x (fx), you already know how to delete from cursor to character x (dfx).
Yes but if I have to start typing I have to press some key to switch modes (i?). That is a no-go for me.
Well, there's no perfect solution. Either it's a modal system like vi, or you have to use modifier keys whenever you want to do something that isn't enter text.
That said, there are tricks to make modal editing less annoying. For example, mapping your CAPS LOCK key to ESC makes switching out of insert mode much easier.
Some commands perform actions and then switch modes all at once for you. To extend the grandparent comment's example, you can use the substitute command, s, instead of the delete command, d, to perform the "delete and switch into insert mode" action with sfx (rather than dfx).
That said, there are tricks to make modal editing less annoying. For example, mapping your CAPS LOCK key to ESC makes switching out of insert mode much easier.
Some commands perform actions and then switch modes all at once for you. To extend the grandparent comment's example, you can use the substitute command, s, instead of the delete command, d, to perform the "delete and switch into insert mode" action with sfx (rather than dfx).
Minor nitpick: c is delete and switch into insert mode, so it would be cfx.
When you say "trying to learn", what do you mean? If you are trying to dive into everything that emacs can do, I'd imagine you will be in a world of pain for quite a while.
Instead, just use it to edit files. After a while, if there is something you are finding would be convenient, search for and or build it.
That said, some obvious points that you will find nice do come by default if you start out with something like prelude. Though, again, just use it to edit files and don't worry about using the keyboard shortcuts that heavily.
If you are highly motivated by the shortcuts, then I would set a pace for learning a few at a time and really get them down first.
For that matter, whether in emacs or atom (or vim/sublime/acme/whatever), it would be rather instructive to see what features are used heavily by folks. Even better if there was a nice listing for what features were discovered, in order and frequency of use.
Is there already a trend/meme for doing something like this? "What I use in my editor?"
Instead, just use it to edit files. After a while, if there is something you are finding would be convenient, search for and or build it.
That said, some obvious points that you will find nice do come by default if you start out with something like prelude. Though, again, just use it to edit files and don't worry about using the keyboard shortcuts that heavily.
If you are highly motivated by the shortcuts, then I would set a pace for learning a few at a time and really get them down first.
For that matter, whether in emacs or atom (or vim/sublime/acme/whatever), it would be rather instructive to see what features are used heavily by folks. Even better if there was a nice listing for what features were discovered, in order and frequency of use.
Is there already a trend/meme for doing something like this? "What I use in my editor?"
I'm still an emacs rookie, but I've already been 'converted' to the point that I try to use emacs every time I need to write text - programming (at least if no IDE is available), text files, LaTeX (what little I've written of it, anyway), word processing if it is feasible to write the text in the editor and then copy paste into a word processor to do the formatting later, editing text boxes in web browsers via a Firefox plugin (`It's All Text!').
The primary reason, at least for non-code text, is that I find it annoying to go back to using stuff like the arrow keys for navigating now that I'm kind of used to the arguably more ergonomic C-f, C-b and friends. So I can echo the sentiment that sticking to the basics of emacs at first can be well worth it.
The primary reason, at least for non-code text, is that I find it annoying to go back to using stuff like the arrow keys for navigating now that I'm kind of used to the arguably more ergonomic C-f, C-b and friends. So I can echo the sentiment that sticking to the basics of emacs at first can be well worth it.
Keep up with emacs. It has has been around for long. Every operating system has it. It has a lot of support and tooling around it. Works great over ssh or just on a plain console. Has good syntax highlighting.
My advice is to just learn 5-10 basic commands. Movement, copy paste, exit, save and open file. Then see how you like it.
My advice is to just learn 5-10 basic commands. Movement, copy paste, exit, save and open file. Then see how you like it.
Emacs is the One True Editor.
Maybe, but ed is the standard text editor.
You are all old, nano is the future!
Other than /s, I wanted to say I am also learning emacs after some years of both vim and st2-3 and I really like it. I have still to stick to a cheat sheet to remember common commands but I am on my way to the Stallmanmination
Other than /s, I wanted to say I am also learning emacs after some years of both vim and st2-3 and I really like it. I have still to stick to a cheat sheet to remember common commands but I am on my way to the Stallmanmination
[deleted]
Just checked the new version briefly. Scrolling performance seems to be much better, especially on a large display with fullscreen editor. Atom is getting pretty decent for daily use.
Haven't been following it too much recently, but just curious, why use it over Sublime?
I still use Sublime mostly. However, Atom seems to have a thriving ecosystem around it. There are a lot of high quality Atom packages. I believe it's mostly because Atom has a more accessible developer interface for newcomers, being it is just a web app. And it's open source.
Also, Sublime seems to be abandoned for a while. Not that it stopped working or anything.. But I believe the lack of development will push people away eventually.
Also, Sublime seems to be abandoned for a while. Not that it stopped working or anything.. But I believe the lack of development will push people away eventually.
I just find it funny that replacing "Atom" with "Emacs" in your argument doesn't feel out of place at all.
Well, Emacs Lisp might be less newcomer friendly and it's not a webapp. But still, thriving ecosystem - check, accessible to developers - check, huge number of packages - check, runs everywhere - check.
Well, Emacs Lisp might be less newcomer friendly and it's not a webapp. But still, thriving ecosystem - check, accessible to developers - check, huge number of packages - check, runs everywhere - check.
The thing Atom has which Emacs doesn't is that it's approachable even if you don't appreciate all the customization and the rich ecosystem. You can sit down with Atom and just explore it like you would any other GUI text editor, and it pretty much behaves exactly like you'd expect without having to learn any obscure commands or shortcuts. You can learn the commands and shortcuts (and explore the ecosystem) as you settle in.
I'm primarily a vim user and I still prefer vim to Atom, but within a day or two of seriously trying out Atom, I was probably up to speed with 90% of the core functionality I use in vim on a day to day basis. That last 10% is a bit of a killer, though. :)
I'm primarily a vim user and I still prefer vim to Atom, but within a day or two of seriously trying out Atom, I was probably up to speed with 90% of the core functionality I use in vim on a day to day basis. That last 10% is a bit of a killer, though. :)
That last 10%... same reason I keep going back to emacs after trying a half dozen other editors that more or less promised to be "the one".
atom works well out of the box. Emacs ... not so much.
Not nagged to buy within an hour of installation, I'd consider that a plus in favor of Atom.
Of course, Atom is open source and has potentially huge community backing to push it forward (vs. pleas for features and fixes to the other editor's seemingly absent overlord).
Of course, Atom is open source and has potentially huge community backing to push it forward (vs. pleas for features and fixes to the other editor's seemingly absent overlord).
I'm also a Sublime user but the fact that Atom is open source might be reason enough to change.
Especially after going full open source, I have a lot of respect for that change (http://blog.atom.io/2014/05/06/atom-is-now-open-source.html). Otherwise I feel it would of gotten stagnate. <3 githubbers
tl;dr At this point: not much. That might change soon, though.
When I switched laptops recently, I made the conscious decision to only install Atom to see how things went...so far so good, although at times it does bog down pretty noticeably, and this is by far my biggest complaint. There's also no alt-drag support (to create a straight line of cursors like Sublime), but that's a fairly small gripe.
I loved the plugin ecosystem for Sublime, and in the short time Atom's been around, the ecosystem has already exploded. Lots of awesome themes and plugins are already available, with more coming every day. The low barrier to entry (most things can be done with JS / CSS) probably has a lot to do with that.
When I switched laptops recently, I made the conscious decision to only install Atom to see how things went...so far so good, although at times it does bog down pretty noticeably, and this is by far my biggest complaint. There's also no alt-drag support (to create a straight line of cursors like Sublime), but that's a fairly small gripe.
I loved the plugin ecosystem for Sublime, and in the short time Atom's been around, the ecosystem has already exploded. Lots of awesome themes and plugins are already available, with more coming every day. The low barrier to entry (most things can be done with JS / CSS) probably has a lot to do with that.
I switched mainly because ST2 was acting up, throwing errors left and right. Considered upgrading to ST3, but there were plenty people discussing bugs in that too, and some plugins I use were not yet compatible. A colleague had invites to spare for Atom beta. Checked it out, found it to be 'just like ST2, just without the crashing part' and stuck with it.
Atom is [more] free than Sublime. You have the freedom to modify its behavior.
Atom is free as in freedom.
I tried scrolling through a 1MB JSON file with all four combinations of React DOM on/off and hardware acceleration on/off. Anything with React on was crashing slow. With React off, hardware accel was maybe slightly better on. Sublime 2 blew Atom away. Chrome had flawless scrolling too (albeit with no syntax highlighting). MacBook Pro running 10.9.3.
Typing text at the end of a 1000-line file seems to be laggier with the React-based editor enabled.
One of my biggest pain points with Atom was the speed. More specifically, the selecting of multiple lines greatly killed performance and made me switch back to Sublime. Glad to here they are making efforts to speed the editor up, I'll give it another go!
Speed was really a killer for me too, it became slow very easily. It also began erroring out of update-checks and package installs, making it feel quite worthy of the beta tag. Look forward to seeing where it is now!
I would love to switch from Sublime Text to Atom, but the two main things holding me back are the noticeable performance issues (compared to ST), and vim keybindings.
ST's vim support is good enough for me, and when I need more I'll just switch to Vim for those things. But Atom unfortunately is still too limited, although it's good to see progress.
Happy to see the performance issues being worked on, though, and as a big fan of React, I'm happy with their choice.
ST's vim support is good enough for me, and when I need more I'll just switch to Vim for those things. But Atom unfortunately is still too limited, although it's good to see progress.
Happy to see the performance issues being worked on, though, and as a big fan of React, I'm happy with their choice.
It gets better every time I try again, but I'm still missing four things:
- Good project management. I tried the project-manager plugin, but it doesn't seem to remember my fuzzy finder options and reindexes everything every time.
- Good Vim emulation, like Vintageous in Sublime.
- Keyboard mapping override. I use cmd-j and cmd-k for switching tabs in Sublime. I cannot map this easily in Atom.
- Actually, I disabled tabs in Sublime and only use the side bar. I miss this in Atom too.
- Good project management. I tried the project-manager plugin, but it doesn't seem to remember my fuzzy finder options and reindexes everything every time.
- Good Vim emulation, like Vintageous in Sublime.
- Keyboard mapping override. I use cmd-j and cmd-k for switching tabs in Sublime. I cannot map this easily in Atom.
- Actually, I disabled tabs in Sublime and only use the side bar. I miss this in Atom too.
This is very interesting. Reminds me of what I saw in Chrome Secure Shell source code while hacking a while back on a vt100 emulator in JS.
ls -l ~ was always the best test to see how scrolling would behave and how fast was the rendering...
What they say here and what I realized then is that the most important part is about rendering only what is visible on the screen!
ls -l ~ was always the best test to see how scrolling would behave and how fast was the rendering...
What they say here and what I realized then is that the most important part is about rendering only what is visible on the screen!
I finally tried Atom and it looks pretty much like SublimeText, which I use quite a bit. Is there a reference somewhere where it says it was inspired by good work of SublimeText editor?
Ah Google always provides:
https://github.com/atom/atom/issues/2038
Ah Google always provides:
https://github.com/atom/atom/issues/2038
Weird behavior with scroll wheel. It seems to not stop where I'd expect. Works great with trackpad, so I guess that's what the developers must be using.
Fast scrolling by dragging the scrollbar nub is pretty slow, still, but this is definitely an improvement.
Fast scrolling by dragging the scrollbar nub is pretty slow, still, but this is definitely an improvement.
What platform? What kind of mouse are you using? The team uses all different mice. I use an apple magic mouse, and it works well.
You can change the scroll sensitivity in the settings.
You can change the scroll sensitivity in the settings.
No mention of the Brackets editor here from Adobe. Also built with JS and open source. Any opinions on it in comparison to Atom? http://brackets.io
Would they gain better performance if they use canvas intead the dom?
they could use WebGL and an engine that supports ASMjs.
But it wouldnt make sense since it's not a web app.
IMHO,it's a mistake to use webtechs to code a serious text editor. TextEds require great performances,if I cant open a 3MB with it,it's just not worth it.
They could have kept javascript/coffeescript for plugins and write the UI in C/C++.Javascript is fast with engines like V8,the DOM is absolutely not fast at all.
IMHO,it's a mistake to use webtechs to code a serious text editor. TextEds require great performances,if I cant open a 3MB with it,it's just not worth it.
They could have kept javascript/coffeescript for plugins and write the UI in C/C++.Javascript is fast with engines like V8,the DOM is absolutely not fast at all.
> We also render the cursors and the hidden input field that receives keyboard events as their own layers on the GPU
How is this performed? transform: translateZ(0)?
How is this performed? transform: translateZ(0)?
[deleted]
After this news, I downloaded and build on windows and yeah it might replace my favorite text editor :)
Why we need another editor? We already have vi, emacs, st, ... Why Atom?
Why do we need cars when we have horse carriages?
Maybe more like why do we need electric cars when we have petrol engines, maybe? IDK.
Maybe we just don't need it, but it's nice to have a different approach / a choice.
Maybe we just don't need it, but it's nice to have a different approach / a choice.
Because they're faster. Atom is slower than Sublime :)
But Atom is free, open source, and actively being developed.
But Atom is free, open source, and actively being developed.
Cars were not faster at the beginning.
You don't know if something will eventually become better unless you try hard.
You don't know if something will eventually become better unless you try hard.
Not really a good analogy, though. There were serious benefits to getting off horses, even if we ignore the speed promise of automobiles. Moving to a text editor that is written in JavaScript doesn't really seem to have much promise of gains in the future.
Though, the enthusiasm there is nice and there is no reason to bemoan its existence. Just don't be surprised when the things it can do have already be done in more venerable environments in the past. :)
Though, the enthusiasm there is nice and there is no reason to bemoan its existence. Just don't be surprised when the things it can do have already be done in more venerable environments in the past. :)