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
Moving Atom to React
131–140 of 142 posts
Re: Moving Atom to React
#132It 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.
Re: Moving Atom to React
#133The 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.
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.
Re: Moving Atom to React
#134Earlier quoted context omitted.
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.)
It does, just not for `untitled` files.
Re: Moving Atom to React
#135Earlier quoted context omitted.
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 animate…
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).
Re: Moving Atom to React
#136Earlier quoted context omitted.
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…
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.
Re: Moving Atom to React
#137Earlier quoted context omitted.
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..)
Yeah, that's been my experience, too (on both counts).
Emacs ftw!
Re: Moving Atom to React
#138Earlier quoted context omitted.
atom works well out of the box. Emacs ... not so much.
How often do most developers set up a new environment? For me, it's nowhere near enough for me to care at all whether my main development tool "works out of the box."
I used emacs for years and I spent far too much time fiddling with it to get it to the place of something like atom.
Re: Moving Atom to React
#139Earlier quoted context omitted.
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 see…
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.
Re: Moving Atom to React
#140A 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.