131–140 of 459 posts
Earlier quoted context omitted.
Welcome to what I've felt with Emacs since I first used it. Might be time to work on some tutorials and examples to make Emacs easier to hack on and contribute to...
I've felt largely the same about vim. I think atom is the GUI'ed equivalent of excellent extensible minimalist command line tools.
I am a paying customer of Sublime Text, but I will give Atom a try. They both seem really similar feature-wise, but Atom is open source, something I care about. Also is based on web technologies, which is really cool (although I've heard it's not so fast).
It pains me to say this as a JS dev, but I think basing it on web tech was a mistake. It makes the app slightly, but noticeably, less responsive. Just recently they posted a big long thing about getting scrolling to be fast. I dunno, I feel like if such things are an issue in 2015 you may have made a mistake.
Earlier quoted context omitted.
No, recent patch increased the limit to blazing 4 MEGABYTES!
Yeah this is crazy. I regularly work with log files in the 100mb to 300mb range which open perfectly fine in Vim/Sublime. If I had to invest time in learning Atom I'd have to multitask between editors for certain use-cases. Maybe if they could switch to a light-weight read-only type of text "viewer" for large files, that would even work. But I really do need to open big files on a weekly basis.
I remember when Atom beta came out I was turned off because it (presumably) didn't run on Windows(my workstation at the time). Then I remember trying to give it a try once again a few months ago but gave up because I've heard so many horror story about performance issues. Now I'm willing to give it yet another try because of vim-bindings and performance issue improvements. Is it at workable state?
Yes, I've used atom every single day since it came out to write my daily notes in markdown and then see them rendered as markup in the markdown previewer.
However after finding out about the vim bindings I've been using it as my primary text editor for the last month and I really like it.
It's got 95% of the `vim` goodness that I use combined w/ the thriving package scene and being able to extend it w/ JS.
FWIW here is a list of the packages which I'm currently using:
https://gist.github.com/cgcardona/79fa3a6dcd329c60c290
* atom-fuzzy-grep * atom-jshint * color-picker * git-plus * highlight-selected * minimap * minimap-autohide * minimap-bookmarks * minimap-find-and-replace * minimap-git-diff * minimap-highlight-selected * minimap-pigments * minimap-selection * pigments * vim-mode
Earlier quoted context omitted.
It's the Cycle of Bloat. 1. Develop tool. It's small and fast and minimal! Woo! 2. It's easy to modify because it's so small! Woo! 3. Look, there's a budding ecosystem of packages! Woo! (Let's not talk about the fact the packages exist precisely because the original product wasn't big enough.) 4. Oh dear, some of them conflict, a lot of them suck. Well, here's some winners, let's pull them into the core. Now the base…
I disagree with your characterization. Take jQuery for example. 1. Small, fast and minimal. 2. Easy to create plugins. 3. Budding ecosystem and explosion of plugins. 4. Conflicts ensued and some plugins got pulled into the core project. Eventually, the growth of jQuery tapered off as the project stabilized. Not only did the size taper off, it got smaller as well. After nearly 10 years, we're talking about a payload o…
Even if it's not actually true (as you've said, it literally is not bloated wrt filesize) people still think it's true.
Just downloaded and opened Atom for the first time, and I have to admit the look and feel is amazing! Fantastic job to all those involved! However, one thing that stands out to me, the file size of Atom.app is 203MB!! How in the world can a text editor be that large? Compare that with MacVim, which is about 27MB.
Earlier quoted context omitted.
It's the Cycle of Bloat. 1. Develop tool. It's small and fast and minimal! Woo! 2. It's easy to modify because it's so small! Woo! 3. Look, there's a budding ecosystem of packages! Woo! (Let's not talk about the fact the packages exist precisely because the original product wasn't big enough.) 4. Oh dear, some of them conflict, a lot of them suck. Well, here's some winners, let's pull them into the core. Now the base…
I disagree with your characterization. Take jQuery for example. 1. Small, fast and minimal. 2. Easy to create plugins. 3. Budding ecosystem and explosion of plugins. 4. Conflicts ensued and some plugins got pulled into the core project. Eventually, the growth of jQuery tapered off as the project stabilized. Not only did the size taper off, it got smaller as well. After nearly 10 years, we're talking about a payload o…
Don't recall claiming everything is under the "cycle of bloat". The fact that I gave specific examples was a pretty big clue that it's not all equal.... and jQuery isn't in any of them, either.
Edit: Sorry, is there something wrong with my pointing out that I didn't ever claim the things being imputed to me?
The killer feature of Atom to me is the ease with which it can be extended (via packages) and the openness to community contribution on core features. That's not a knock against any other editor (some of which share similar characteristics in this regard) – it's just what draws me to Atom. It's super easy to hack on and contribute to.
It's the Cycle of Bloat. 1. Develop tool. It's small and fast and minimal! Woo! 2. It's easy to modify because it's so small! Woo! 3. Look, there's a budding ecosystem of packages! Woo! (Let's not talk about the fact the packages exist precisely because the original product wasn't big enough.) 4. Oh dear, some of them conflict, a lot of them suck. Well, here's some winners, let's pull them into the core. Now the base…
Earlier quoted context omitted.
That's really only a problem if you're contributing to the core, right? You can write your own packages in JS, and if you're just a user of the editor I don't see how that matters.
Sure, you can write your own packages in vanilla JS. Unfortunately though all of the documentation (and most packages themselves) are all written in coffeescript. Basically, the only way you can write a plugin in Javascript is if you already know Coffeescript (at least enough to read it). It's just one extra barrier of entry for non-coffeescript developers. I personally thought about writing a simple plugin, went to…
Congrats! I still prefer emacs but perhaps not for long (I use both day to day)...