Moving Atom to React
71–80 of 142 posts
Re: Moving Atom to React
#72Not 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?)
My advice is to just learn 5-10 basic commands. Movement, copy paste, exit, save and open file. Then see how you like it.
Re: Moving Atom to React
#73Re: Moving Atom to React
#74Not 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?)
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 ).…
> 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.
Re: Moving Atom to React
#75So 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 :)
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.
Re: Moving Atom to React
#76Re: Moving Atom to React
#77Earlier 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
Re: Moving Atom to React
#78Earlier quoted context omitted.
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 ).…
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.
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).
Re: Moving Atom to React
#79Earlier quoted context omitted.
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.
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.
Re: Moving Atom to React
#80Not 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?)
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…