Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I fixed a bug in Atom

davidvgalbraith.com

Post reply on HN
Print view View original

141–150 of 189 posts

Re: How I fixed a bug in Atom

#141

Post by dragonwriter »

kcbanner wrote: post #94

I am still unsure why anyone uses Atom when it consumes so many resources. The emacs instance I have had open for some time now is using 92Mb. Atom instances have been reported in the hundreds of megabytes [1]. Of course, this is because it is actually a web application running in an entire browser, renderer and helper processes included. I understand the need for people to be able to "easily" hack on it (easily in q…

> I am still unsure why anyone uses Atom when it consumes so many resources. The emacs instance I have had open for some time now is using 92Mb. Atom instances have been reported in the hundreds of megabytes [1].

It works well on the size files I mostly want to use it with, has a strong community producing support for the languages I want to use it with, doesn't want to impose its own structure and management artifacts on projects the way IDEs tend to, and imposes less cognitive overhead than Emacs [0]. It might use more memory, but that's never been a real practical problem, and even on my cheap 6Gb RAM laptop system, the difference between a programming editor taking up ~100Mb and "hundreds of Mb" just isn't an issue in most cases.

[0] I recognize that this is largely due to familiarity, in that Atom follows closer to currently-popular UX paradigms and Emacs is its own unique beast that predates most of the things that Atom is following, but I've been using Emacs intermittently for many years, and Atom was still instantly more accessible. But even so, there are some languages where the available Emacs packages are so good that I prefer Emacs. Just as there are some things for which I prefer Visual Studio or an IntelliJ-based IDE. Its not like one tool is ideal for every person for every task.

Re: How I fixed a bug in Atom

#142

Post by zeveb »

anon4 wrote: post #95
kcbanner wrote: post #94

I am still unsure why anyone uses Atom when it consumes so many resources. The emacs instance I have had open for some time now is using 92Mb. Atom instances have been reported in the hundreds of megabytes [1]. Of course, this is because it is actually a web application running in an entire browser, renderer and helper processes included. I understand the need for people to be able to "easily" hack on it (easily in q…

Because it has a friendly interface, while Vim and Emacs have all these "weird" keybinds and whatnot. These are people switching from e.g. SublimeText to Atom. I am not trying to harp on Vim or Emacs, I myself am a Vim user and use it for C++ code.

> Because it has a friendly interface, while Vim and Emacs have all these "weird" keybinds and whatnot.

vim and emacs are friendly and welcoming to people who already know them; new users in 2016 have some weird expectations due to growing up using insufficiently-powerful UIs, which means that they have quite a learning curve when picking up a powerful UI.

Re: How I fixed a bug in Atom

#143

Post by wmonk »

random_rr wrote: post #112
wmonk wrote: post #56

While this was a good read, should it not be titled: # How I fixed the 'atom/language-go' package

No, he fixed a function of Atom, the original title is valid.

The regex he fixed was committed into the package atom/language-go, not into atom core. It was only an issue when writing go code.

Re: How I fixed a bug in Atom

#144

Post by jarcane »

pilif wrote: post #110

In general, when you are working on a problem and you think "let me use a regex for that" and then you come up with ^\s*[^\s()}]+(? [^()]*\((?:\g |[^()]*)\)[^()]*)*[^()]*\)[,]?$ to solve your problem, then you have IMHO come across a problem which you should not be solving using regular expressions. Case in point is counting and balancing parentheses which is very easily done using a single loop over the string in qu…

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems. -- Jamie Zawinski

To which I might dare add, "... and so does whomever next has to read this code."

Re: How I fixed a bug in Atom

#145

Post by dragonwriter »

zeveb wrote: post #142
anon4 wrote: post #95

Earlier quoted context omitted.

Because it has a friendly interface, while Vim and Emacs have all these "weird" keybinds and whatnot. These are people switching from e.g. SublimeText to Atom. I am not trying to harp on Vim or Emacs, I myself am a Vim user and use it for C++ code.

> Because it has a friendly interface, while Vim and Emacs have all these "weird" keybinds and whatnot. vim and emacs are friendly and welcoming to people who already know them; new users in 2016 have some weird expectations due to growing up using insufficiently-powerful UIs, which means that they have quite a learning curve when picking up a powerful UI.

> vim and emacs are friendly and welcoming to people who already know them; new users in 2016 have some weird expectations due to growing up using insufficiently-powerful UIs, which means that they have quite a learning curve when picking up a powerful UI.

Having first used both vi and emacs (and other text-mode - and even line-mode -- editors), though only casually then, I disagree; vi and emacs are, like almost anything, friendly and welcoming to people who have become deeply familiar with them, but they simply aren't as accessible as tools that benefit from the advances in the intervening years in making UIs easy to use for people that haven't invested huge amounts of time in familiarity.

This is really a different issue than UI power (though if vim and emacs didn't have both powerful UIs and substantially bodies of users with long investments, they wouldn't stick around in the face of their disadvantages in terms of onramp.)

Older users just didn't, when they were new, have alternatives with a simpler learning curve. So, there really was no trade off for the power vi and emacs offered (less powerful alternatives of the time were still just as inaccessible), where now there is.

Re: How I fixed a bug in Atom

#146

Post by mwcampbell »

fuzionmonkey wrote: post #49
spinningarrow wrote: post #37

> This defines a named capture group, . I thought JavaScript regexes don't support named capturing groups. Is Atom using some library or custom functionality for that? EDIT: Or is it a CoffeeScript addition? In their table of contents I only see regex blocks mentioned though ( http://coffeescript.org/#regexes ).

https://github.com/atom/node-oniguruma

Would switching to standard JS regular expressions substantially improve Atom's performance, even though it would mean losing some advanced regex features? I remember hearing that V8 JIT-compiles regular expressions to native code.

Re: How I fixed a bug in Atom

#147

Post by zeveb »

dragonwriter wrote: post #145
zeveb wrote: post #142

Earlier quoted context omitted.

> Because it has a friendly interface, while Vim and Emacs have all these "weird" keybinds and whatnot. vim and emacs are friendly and welcoming to people who already know them; new users in 2016 have some weird expectations due to growing up using insufficiently-powerful UIs, which means that they have quite a learning curve when picking up a powerful UI.

> vim and emacs are friendly and welcoming to people who already know them; new users in 2016 have some weird expectations due to growing up using insufficiently-powerful UIs, which means that they have quite a learning curve when picking up a powerful UI. Having first used both vi and emacs (and other text-mode - and even line-mode -- editors), though only casually then, I disagree; vi and emacs are, like almost any…

> So, there really was no trade off for the power vi and emacs offered (less powerful alternatives of the time were still just as inaccessible), where now there is.

There's simply nothing out there as good as emacs. Nothing. Eclipse, IntelliJ, Atom, SublimeText, all those pale in comparison. vim has its positive points (it's an excellent way for a human to edit line-oriented text), but ultimately it too falls down in the general case. emacs is simply the best way for a human being to use a computer to edit data.

There still isn't an alternative to vim and emacs. I kinda wish there were, but there ain't. Someday I'd like to use a modern emacs-like editor, implemented in Common Lisp (or a successor language), but right now emacs is the pinnacle of editor evolution.

Re: How I fixed a bug in Atom

#148

Post by zenocon »

sergiotapia wrote: post #140
zenocon wrote: post #66

Here's another one that needs to get fixed with Atom. Try writing this in the editor with syntax set to Go: expected func someFunc() { aSlice := []string{}{ } } actual func someFunc() { aSlice := []string{}{ } } The end bracket on the slice's initializer never indents correctly when you type it and hit . It always defaults to the first character of the next line. It seems insertNewLine somehow is not able to grok the…

Install the go-plus package and it'll `go fmt` on save everytime, saving you this headache. Works seamlessly.

Thanks for the tip -- yea, I have go-plus installed. It is helpful, but still isn't ideal to have to save the file in the middle of trying to initialize a slice.

Re: How I fixed a bug in Atom

#149

Post by boulos »

HeXetic wrote: post #107
boulos wrote: post #11

I got to the bottom and couldn't believe that the solution chosen was to modify the regexp instead of use a for loop. He did such a great job explaining that the code is really just trying to count the number of parentheses or braces to see if they're imbalanced, that it felt the next step was "so I wrote a really simple set of loops that is fast enough on short strings and way less crazy otherwise".

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. - Jamie Zawinski

Just so you know, jwz is not the original source of this quote, it's much older: http://regex.info/blog/2006-09-15/247

Re: How I fixed a bug in Atom

#150

Post by omaranto »

mbrock wrote: post #81
Grue3 wrote: post #50

Earlier quoted context omitted.

Jesus, how did nobody catch this before? The least a code editor should do is to match parentheses correctly.

I've never used a language mode that worked properly in all cases. That's why I've stopped using them, aside from very clever and extraordinarily useful ones like paredit. It terrifies me to think about how these language modes contain regexps for matching regexp syntax. Of course those are wrong.

The Textadept editor uses PEGs for its language modes. I haven't tested them but that sounds like it has a chance of being pretty good.
Post reply on HN