> we’ve been focusing on making basic text editing smoother and more responsive
This REALLY shouldn't be an issue with basic text editing in any text editor
Moving Atom to React
101–110 of 142 posts
Re: Moving Atom to React
#102Would they gain better performance if they use canvas intead the dom?
at that point you may as well just write it from scratch.
You would have to write your own text layout engines and everything.
Re: Moving Atom to React
#103Just 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 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.
Re: Moving Atom to React
#104Having 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.
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.
Re: Moving Atom to React
#105Earlier quoted context omitted.
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 s…
Have you tried LightTable yet?
Yes, I really like its philosophy, but it had some rendering issues when I tried.
Also, I've yet to accept that javascript is taking over (Atom, Lighttable..)
Re: Moving Atom to React
#106Earlier quoted context omitted.
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.
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.
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
Re: Moving Atom to React
#107Earlier quoted context omitted.
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…
"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: ExtensionComponent.prototype = Object.create(Component.prototype); function ExtensionComponent() { Component.call(this); } ExtensionComponent.pro…
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:
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.Re: Moving Atom to React
#108Earlier quoted context omitted.
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.
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.
Re: Moving Atom to React
#109Earlier quoted context omitted.
Because they're faster. Atom is slower than Sublime :) 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.
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. :)
Re: Moving Atom to React
#110Earlier quoted context omitted.
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.
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 Much more sensible for me than the reopen every single project I had open last time .
This is incorrect: unlike Sublime, Atom does not persist unsaved files across restarts.
(If step (2) is "create new file", Sublime will preserve it, even if it's not saved.)