11 ms·

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 no

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.

omouse 11y ago
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...
- davidshepherd7 11y ago
  The ease of installing packages in Emacs has improved hugely in the last few years, so I think it's getting better for beginners already.
  - outworlder 11y ago
    Indeed. For example: http://tullo.ch/articles/modern-emacs-setup/ http://tullo.ch/articles/modern-emacs-setup/
- kajecounterhack 11y ago
  I've felt largely the same about vim. I think atom is the GUI'ed equivalent of excellent extensible minimalist command line tools.
  - afarrell 11y ago
    You have felt it is easy to install, debug, and write vim plugins? As a vim user, I am super curious how?
    - palmer 11y ago
      Installing and managing plugins at least is pretty easy with pathogen and vundle.
      - kajecounterhack 11y ago
        And for writing: https://github.com/google/vim-maktaba https://github.com/google/vim-maktaba
- jflatow 11y ago
  Yes. I keep trying to like Atom because I want to have native WebView buffers while I'm editing. Every time I try it, I end up wondering how anyone can be comfortable using it. I'm not sure how much of that is due to instability that will be fixed over time, and how much is because I'm coming from Emacs. Have any experienced Emacs users found that Atom makes them more productive in any dimension? I want to like it but I can't see the light at the end of the tunnel.
  - davexunit 11y ago
    >Have any experienced Emacs users found that Atom makes them more productive in any dimension? No. Emacs is far and away superior. It doesn't have a flashy web UI, but it is better in every way that matters.
  - danneu 11y ago
    My custom Emacs init file that's grown over the years reminds me of my main problem with Emacs: to do anything, it just feels like a bunch of magical incantations using global variables and function calls I wouldn't know how to discover on my own. Random example from my user.el file: (set-cursor-color "White") (setq blink-cursor-interval 0.5) With some trial and error, I could find out if `(setq cursor-color "White")` works. Or see if `set-blink-cursor-interval` exists. Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable. Or find some best Emacslisp practices online. Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch. But I just can't be bothered anymore. Seems like Atom is having an easy time beating Emacs on this front, and I'll probably switch over for good the next time something breaks in my .emacs.d folder.
    - webkike 11y ago
      I think you'll find that Atom is going to be the exact same, but with Javascript.
      - kansface 11y ago
        No, Atom's API is probably an order of magnitude smaller than Emacs.
jastanton 11y ago
While I see that as a strength it might be a double edged sword. I installed a few packages I thought were necessary and soon Atom was crashing constantly and was riddled with bugs. I think it's possible that too many people have the ability to control core pieces of what makes Atom so good and as a result the experience degrades.
- pvdebbe 11y ago
  The inverse also applies. Take Chrome/Chromium where the extensions are generally powerless against core components, making the whole browser useless for decent customization.
jerf 11y ago
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 system is that much better! Woo! 5. Repeat 3 and 4 a few times. 6. Crap, this tool is all bloated and slow. I'm going to go create a small, fast, minimalist solution! Repeat indefinitely. See also: "minimalist web framework", "minimalist Linux distribution", "minimalist programming language".
- crusso 11y ago
  There are projects like Linux Kernel, Mercurial, and Rails that have managed to be very extensible and have had good leadership in knowing what to put into core and what to cut from core as time goes on.
  - jerf 11y ago
    Well, I know for sure I've witnessed people say #6 about the Linux Kernel and Rails multiple times. So for what it's worth, I'm very unconvinced that "bloat" is the automatically-bad thing that whoever is saying #6 says it is. There are things that are just crappy amalgamations of whatever, sure, but there are also a lot of big things that solve hard problems, and part of the implication of the cycle is that every time a #6 pops up and starts a new project, (s)he is inevitably beginning on a journey of discovery in which (s)he will discover why the previous tool got big. Big problems require big solutions. And it turns out that "text editing" looks really simple, and gets really not simple really fast. Same for the other two things. I've literally lost count of the minimalistic text editors with great plugin interfaces that have paraded by me at this point. (And... uh... how can I put this delicately... writing a good web framework is actually a non-trivial exercise. The web is complicated to do it right. If you've got a 250-line web "framework", odds are what you've got is 250 lines that sorta kinda work as long as nobody tries to hack it and nobody cares about actual compliance with all of the implicit and explicit standards embedded in HTTP. It may be suitable for your blog, it may be suitable for a 3-call API, but it's probably not suitable for anywhere near as many things as you'd like. And it's probably brutally insecure somehow.)
sklogic 11y ago
How exactly it is easier to extend than emacs?
lettergram 11y ago
This is kinda the reason that you have quite a few die hard emacs fans.
ffk 11y ago
The trick is to not pull them into core. Let others curate a set of high quality plugins. This is exactly what is happening. Examples include Microsoft's Visual Studio Code and Facebooks Nuclide. This pattern is also not uncommon. There are many high quality linux modules and distributions built on the linux kernel. It is likely atom will take a similar architectural approach. Make it easy to build and add plugins and let the community shepherd them.
- carussell 11y ago
  Visual Studio Code is not a set of Atom plugins.
r0muald 11y ago
Still, there are six "highlight features" right on the home page: - Cross-platform editing - Built-in package manager - Smart autocompletion - File system browser - Multiple panes - Find and replace Is it me, or most of these are so basic that of course any text editor would have at least this set from the start? Right, autocompletion came in several steps for Atom, but .. I have used Atom for a while and it seems to understate the real advantages over other editors, such as: it's a GitHub product! Which brings me to the part where I couldn't stand Atom: I should be able to do any git operation strsight from Atom, no configuration files needed, with a default plugin! Instead, we are left with many community plugins, like git-diff and atomagit. I hope things will evolve in a way similar to autocomplete.

omouse 11y ago

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

davidshepherd7 11y ago
The ease of installing packages in Emacs has improved hugely in the last few years, so I think it's getting better for beginners already.
- outworlder 11y ago
  Indeed. For example: http://tullo.ch/articles/modern-emacs-setup/ http://tullo.ch/articles/modern-emacs-setup/
kajecounterhack 11y ago
I've felt largely the same about vim. I think atom is the GUI'ed equivalent of excellent extensible minimalist command line tools.
- afarrell 11y ago
  You have felt it is easy to install, debug, and write vim plugins? As a vim user, I am super curious how?
  - palmer 11y ago
    Installing and managing plugins at least is pretty easy with pathogen and vundle.
    - kajecounterhack 11y ago
      And for writing: https://github.com/google/vim-maktaba https://github.com/google/vim-maktaba
jflatow 11y ago
Yes. I keep trying to like Atom because I want to have native WebView buffers while I'm editing. Every time I try it, I end up wondering how anyone can be comfortable using it. I'm not sure how much of that is due to instability that will be fixed over time, and how much is because I'm coming from Emacs. Have any experienced Emacs users found that Atom makes them more productive in any dimension? I want to like it but I can't see the light at the end of the tunnel.
- davexunit 11y ago
  >Have any experienced Emacs users found that Atom makes them more productive in any dimension? No. Emacs is far and away superior. It doesn't have a flashy web UI, but it is better in every way that matters.
- danneu 11y ago
  My custom Emacs init file that's grown over the years reminds me of my main problem with Emacs: to do anything, it just feels like a bunch of magical incantations using global variables and function calls I wouldn't know how to discover on my own. Random example from my user.el file: (set-cursor-color "White") (setq blink-cursor-interval 0.5) With some trial and error, I could find out if `(setq cursor-color "White")` works. Or see if `set-blink-cursor-interval` exists. Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable. Or find some best Emacslisp practices online. Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch. But I just can't be bothered anymore. Seems like Atom is having an easy time beating Emacs on this front, and I'll probably switch over for good the next time something breaks in my .emacs.d folder.
  - webkike 11y ago
    I think you'll find that Atom is going to be the exact same, but with Javascript.
    - kansface 11y ago
      No, Atom's API is probably an order of magnitude smaller than Emacs.

jastanton 11y ago

While I see that as a strength it might be a double edged sword. I installed a few packages I thought were necessary and soon Atom was crashing constantly and was riddled with bugs. I think it's possible that too many people have the ability to control core pieces of what makes Atom so good and as a result the experience degrades.

pvdebbe 11y ago
The inverse also applies. Take Chrome/Chromium where the extensions are generally powerless against core components, making the whole browser useless for decent customization.

jerf 11y ago

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 system is that much better! Woo! 5. Repeat 3 and 4 a few times. 6. Crap, this tool is all bloated and slow. I'm going to go create a small, fast, minimalist solution! Repeat indefinitely. See also: "minimalist web framework", "minimalist Linux distribution", "minimalist programming language".

crusso 11y ago
There are projects like Linux Kernel, Mercurial, and Rails that have managed to be very extensible and have had good leadership in knowing what to put into core and what to cut from core as time goes on.
- jerf 11y ago
  Well, I know for sure I've witnessed people say #6 about the Linux Kernel and Rails multiple times. So for what it's worth, I'm very unconvinced that "bloat" is the automatically-bad thing that whoever is saying #6 says it is. There are things that are just crappy amalgamations of whatever, sure, but there are also a lot of big things that solve hard problems, and part of the implication of the cycle is that every time a #6 pops up and starts a new project, (s)he is inevitably beginning on a journey of discovery in which (s)he will discover why the previous tool got big. Big problems require big solutions. And it turns out that "text editing" looks really simple, and gets really not simple really fast. Same for the other two things. I've literally lost count of the minimalistic text editors with great plugin interfaces that have paraded by me at this point. (And... uh... how can I put this delicately... writing a good web framework is actually a non-trivial exercise. The web is complicated to do it right. If you've got a 250-line web "framework", odds are what you've got is 250 lines that sorta kinda work as long as nobody tries to hack it and nobody cares about actual compliance with all of the implicit and explicit standards embedded in HTTP. It may be suitable for your blog, it may be suitable for a 3-call API, but it's probably not suitable for anywhere near as many things as you'd like. And it's probably brutally insecure somehow.)

sklogic 11y ago

How exactly it is easier to extend than emacs?

lettergram 11y ago

This is kinda the reason that you have quite a few die hard emacs fans.

ffk 11y ago

The trick is to not pull them into core. Let others curate a set of high quality plugins. This is exactly what is happening. Examples include Microsoft's Visual Studio Code and Facebooks Nuclide. This pattern is also not uncommon. There are many high quality linux modules and distributions built on the linux kernel. It is likely atom will take a similar architectural approach. Make it easy to build and add plugins and let the community shepherd them.

carussell 11y ago
Visual Studio Code is not a set of Atom plugins.

r0muald 11y ago

Still, there are six "highlight features" right on the home page: - Cross-platform editing - Built-in package manager - Smart autocompletion - File system browser - Multiple panes - Find and replace Is it me, or most of these are so basic that of course any text editor would have at least this set from the start? Right, autocompletion came in several steps for Atom, but .. I have used Atom for a while and it seems to understate the real advantages over other editors, such as: it's a GitHub product! Which brings me to the part where I couldn't stand Atom: I should be able to do any git operation strsight from Atom, no configuration files needed, with a default plugin! Instead, we are left with many community plugins, like git-diff and atomagit. I hope things will evolve in a way similar to autocomplete.