Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving Atom to React

blog.atom.io

Post reply on HN
Print view View original

121–130 of 142 posts

Re: Moving Atom to React

#121

Post by tree_of_item »

TheZenPsycho wrote: post #108
silversmith wrote: post #100

Earlier quoted context omitted.

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 n…

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.

Re: Moving Atom to React

#122

Post by aikah »

jbeja wrote: post #54

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.

Re: Moving Atom to React

#123

Post by purephase »

JoelHobson wrote: post #60
lelandbatey wrote: post #57

Earlier 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.

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

Although it advertises persistence, it doesn't look like it works. Everything I put in there is gone upon restart.

Interesting idea though. Thanks for pointing it out.

Re: Moving Atom to React

#124

Post by nilkn »

snotrockets wrote: post #84
nilkn wrote: post #82

Earlier quoted context omitted.

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." 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 ed…

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.

Re: Moving Atom to React

#125

Post by alextgordon »

TheZenPsycho wrote: post #108
silversmith wrote: post #100

Earlier quoted context omitted.

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 n…

> 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.

Re: Moving Atom to React

#126

Post by Ixiaus »

silversmith wrote: post #100
lelandbatey wrote: post #57

Earlier 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.

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 :)

Re: Moving Atom to React

#127

Post by reitanqild »

tree_of_item wrote: post #121
TheZenPsycho wrote: post #108

Earlier quoted context omitted.

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 n…

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. )

Re: Moving Atom to React

#128

Post by reitanqild »

nilkn wrote: post #124
snotrockets wrote: post #84

Earlier quoted context omitted.

> 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 ed…

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.

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. )

Re: Moving Atom to React

#129

Post by [deleted] »

reitanqild wrote: post #128
nilkn wrote: post #124

Earlier quoted context omitted.

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.

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]

Re: Moving Atom to React

#130

Post by adamcw »

reitanqild wrote: post #127
tree_of_item wrote: post #121

Earlier quoted context omitted.

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. )

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.)

Post reply on HN