4 ms·

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 t

by cnp 12y ago

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

notduncansmith 12y ago
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.
- TimWolla 12y ago
  There is a git-diff package that shows colored bars next to the line numbers: https://github.com/atom/git-diff https://github.com/atom/git-diff. While not a real diff I find it pretty helpful.
  - notduncansmith 12y ago
    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).

by cnp 12y ago

notduncansmith 12y ago

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.

TimWolla 12y ago
There is a git-diff package that shows colored bars next to the line numbers: https://github.com/atom/git-diff https://github.com/atom/git-diff. While not a real diff I find it pretty helpful.
- notduncansmith 12y ago
  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).