Live data from Hacker News

Atom 1.0

blog.atom.io

251–260 of 459 posts

Re: Atom 1.0

#251
post #175

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.

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 an…

Visual Studio Code is not a set of Atom plugins.

Re: Atom 1.0

#252
post #124

Earlier quoted context omitted.

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…

While this is true, and I love JQuery, there's a significant number of JavaScript programmers who do say that JQuery is bloated and slow and old and you shouldn't use it. http://youmightnotneedjquery.com/ and all that. Even if it's not actually true (as you've said, it literally is not bloated wrt filesize) people still think it's true.

My point wasn't if jQuery is a bloated library or not, but whether its plugin system caused it to bloat beyond its original purpose.

Re: Atom 1.0

#253

Atom is the ONLY editor which cannot handle my keyboard layout properly so I can't write brackets :D ([]) I reported it on the first day when the alpha came out, still no fix for this. Let me put it this way: I CAN'T WRITE BRACKETS IN A TEXT EDITOR. LOL

I can't use half the keybindings in my spanish keyboard lol.

Re: Atom 1.0

#254
post #230
post #198

Earlier quoted context omitted.

The problem is you haven't given a single example of any software that fits the model, and people are continuing to provide counter-examples. I can make lists too, if that's all we're doing. 1. Get a cat. 2. Cat requires playtime or they ruin your stuff and can be annoying. 3. Repeat 1 and 2 a few times. 4. You are a crazy cat man.

"The problem is you haven't given a single example of any software that fits the model," Of course not. It's categories of software that have the cycle of bloat. I named three, by implication "text editors" are a fourth. Based on the way people seem to be blinded by the word "bloat" naming specific examples would be seen as an attack, followed by vigorous defenses of how it's not "bloat", which, at least as far as I'…

> Pretty much every text editor ever has started out as a "lean, fast" text editor. And then they grew.

Not Notepad. http://notepadconf.com

Re: Atom 1.0

#255
post #60

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…

Yeah the moment people realise this they tend to start to learn the basics of an old, bloated but still maintained and loved tool like emacs or vim in the case of editors. Nobody wants to relearn the same things over and over again every three years. And you can't really get away from the disadvantages software has (either too small or too bloated). But these old tools will stay.

I can't access it, but I bet even my WIFI router, tv and PS4 have a vi somewhere laying around, ready to help with debugging in case a corresponding core developer comes around to take a look.

Re: Atom 1.0

#256
post #216

Earlier quoted context omitted.

> And it turns out that "text editing" looks really simple, and gets really not simple really fast. Text editing is really simple. The problem is that plain text editors are mostly only used by coders. (Non-coders who want to write text use Word.) And coders want features like syntax coloring, autocompletion, split views, multi-file management, etc. Features that would be of no use to someone writing a quick email or…

Text editing is not simple. Not since Unicode is a thing. And it's not because of Unicode, it's because of us humans and our crazy languages.

Totally agree with you there. I've been reading over the Unicode spec and some of it makes my head spin. I would have never imagined the required level of complexity beforehand.

Re: Atom 1.0

#257

Atom is the ONLY editor which cannot handle my keyboard layout properly so I can't write brackets :D ([]) I reported it on the first day when the alpha came out, still no fix for this. Let me put it this way: I CAN'T WRITE BRACKETS IN A TEXT EDITOR. LOL

I can't use half the keybindings in my spanish keyboard lol.

I'm on a spanish keyboard and it works for me {çñ¬#%|ª}, etc. so there might be something that you can do!

Re: Atom 1.0

#258
post #204

Earlier quoted context omitted.

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 bu…

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")…

> I wouldn't know how to discover on my own.

Go read the manual. I mean, I know it's not cool to read books, and manuals at that, but the Emacs Lisp and Emacs manuals (available in info format for viewing directly in Emacs, among other) are well written and there's a wealth of information there. Even relatively low-level stuff gets explained quite well. And also, try using the help system/apropos tool. It's great for finding functions and variables. Lastly, you can always issue "find-function" or "find-library" which will take you directly to the source code.

> With some trial and error, I could find out if `(setq cursor-color "White")` works.

Use iELM session for this (M-x ielm). You'll get Elisp REPL, where you can write expressions and it'll show you their values. In this case:

  ELISP> cursor-color
  *** Eval error ***  Symbol's value as variable is void: cursor-color
so, no.

> Or see if `set-blink-cursor-interval` exists.

In ielm:

  (symbol-function 'set-blink-cursor-interval) ;; (no, it doesn't)
Via help system: C-h a; then input the name.

> Or look up why `set-cursor-color` exists in the first place when surely it's more consistent to just modify a config variable.

Don't know why is is so, but you can possibly find some explanation in the source code. `set-cursor-color` is defined in /usr/local/share/emacs/25.0.50/lisp/frame.el.gz on my system on line 1223. You can get there with M-x find-function.

> Or find some best Emacs lisp practices online.

Does it really have to be online? There is a full book for this: "Writing GNU Emacs Extensions". It's old, but solid. [EDIT: and also https://www.gnu.org/software/emacs/manual/pdf/eintr.pdf]

> Or figure out why I could never get working my one attempt to write a custom function to scratch my own itch.

Sorry to break it to you, but if it's not working it's because you coded it wrong. All my defuns do work...

BTW, do you know that you can one-step Elisp code with a built-in debugger? Just find a defun, eval it via C-u C-M-x and you'll get breakpoint at the defun entry.

Re: Atom 1.0

#259
post #249

I tried atom, the only thing I liked about it was design and color scheme, the rest are superior in sublime text, so I just went ahead and created a theme/color scheme for sublime which matches atom (1). Atom is laggy, even basic file navigation using arrows can be slow sometimes (and I have a latest retine macbook pro). But the biggest issue for me is a battery usage, it reduces my battery usage on RMBP15 by 2 hours…

> https://goo.gl/tF6M4C – this goo.gl shortlink has been disabled. It was found to be violating our Terms of Service.

----

For what an isolated anecdote is worth, I originally switched from Textmate to Sublime because I preferred Sublime's default colour scheme. Not for any trivial reason like features or "being in active development".

Re: Atom 1.0

#260
post #206

Earlier quoted context omitted.

CoffeeScript is actually pretty cool, from a few minutes spent with it it was just syntaxic sugar for js. Why don't you like it?

Did you miss that you can't create local variables?

you can if you cheat: http://coffeescript.org/#try:%0Aa%20%3D%201%0Ax%20%3D%20-%3E...

(I jumped ship to babel though)

Post reply on HN