
How I fixed a bug in Atom - Garbage
http://davidvgalbraith.com/how-i-fixed-atom/
======
clay_to_n
I liked this article a lot. A programmer found a bug in something he uses
every day, and learned enough to fix it.

I think articles like this are very useful to beginner/intermediate
developers. Everyone in software says "write open source code", "make pull
requests to code you use" etc, but there's a very big gap between knowing how
to program and knowing how to track down, fix, and submit a PR for a bug in a
program (and language!) you've never worked on before.

This is a good little tutorial on ways to attack a bug in a program. I
especially like that he starts with two print statements - there's no wizardry
here, just a programmer digging into a bug.

~~~
sanderjd
Absolutely. I think articles like this are the best way to demystify some of
the stuff that seems a bit magical in working software. Things that look
complex are rarely the product of genius, but rather of a long string of
practical and sometimes painstaking, but fundamental logical problem-solving.

------
cyphar
First of all, this is why people should stop adding stupid features to regular
expressions. A sane regular expression implementation has __no __pathological
cases. DFA generation can be done in O(n^2) from memory (in the absolute worst
case O(n) is average), and matching can 't be worse than O(m) or similar (n is
the size of the regex and m the size of the string). When you add features
like back references and recursive matches, you bring the worst case
complexity to O(a^n), which is exponential.

And why? So you could write some dirty hack rather than writing a simple
recursive descent parser to create an AST of the code (which takes O(n)). What
did you gain by ruining your regular expression implementation and writing
shitty code?

EDIT: Matching _might_ be O(m), but I'm wondering about maximally linked
graphs with many epsilon edges. The conversion from DFA to NFA would require
O(n^2) in that case. Implementing it as an NFA evaluation might be faster than
full conversion, but then you run the risk of having O(n^2) dominating in the
matching.

EDIT: The author is somewhat correct on what "catastrophic back referencing"
is. While you could argue that it is due to bad implementations of the greedy
matching, it's a more endemic problem of how you have to implement a regular
expression engine that supports back references. If you have to support back
references, then you will always have a class of pathological cases which
cause exponential time complexity. I had a useful graph about this on my toy
regular expression engine (which performs much better than Python's
implementation even though it's written in Python and not C):
[https://github.com/cyphar/redone](https://github.com/cyphar/redone).

~~~
JetSetWilly
I don't always want to spend insane amounts of time writing full AST parsers.
Sometimes it is a lot easier to write a simple, hacky, throwaway regex. It's a
bit much to claim that backtracking regular expressions, a very useful tool
sometimes, should never ever be used and everybody should waste loads of time
writing careful code even in situations where it isn't required.

The problem is not the tool. The problem is using the tool for the wrong job -
although who knows, maybe if they didn't just chuck out a quick hacky
implementation, then atom simply wouldn't have the feature at all - in which
case it is a trade-off between having the feature at all and an evidently tiny
corner case bug that was easily fixed by someone who isn't even a regular
developer of the project.

So I don't see the reason to be outraged or judgemental here.

~~~
jerf
"I don't always want to spend insane amounts of time writing full AST
parsers."

This is an effect of the language, not the problem space. Backtracking REs
make it very easy to write bad code, and then most languages make writing the
parsing code hard.

If you're in a language that makes parsing code easier, like Haskell, then the
tradeoff isn't anywhere near so bad. I don't mention Haskell just because it's
the trendy thingy, I mention it because parser combinators really do make for
some very easy parsers, and while parser combinators can exist in other
languages they tend to be very syntactically heavyweight. Perl 6 is supposed
to make parsing perhaps even easier, but I haven't played with it to know.

Parsing isn't really that hard, it just plays very poorly with Algol-inspired
syntax.

To be clear, since this is the Internet and the presumption of disagreement is
strong, this post is not an explanation of why you're wrong... it's an
explanation of why you're _right_. It is absolutely a true statement that in
most languages you're way better off bashing out a dangerous RE than writing a
proper parser even for something as simple as this.

~~~
rspeer
Haskell is, in fact, a _really good_ way to write parser code. That's the main
thing I use Haskell for.

But how are you suggesting that Haskell could solve the problem of letting
CoffeeScript plugins express which text they should apply to in a CoffeeScript
text editor?

~~~
paulddraper
He's not suggesting that.

He's suggesting that the correct solution (recursive descent parser) is not
inherently hard, but CoffeeScript makes it hard enough that people reach for
less good approaches.

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

~~~
viraptor
Same here. Also, I don't use Atom, but looking at the expression I'm pretty
sure it fails to account for strings with parentheses. The way the matching is
done, it looks like it will happily count:

    
    
        func("some call :)")
    

as extra closing paren. (regex101 agrees)

~~~
Lazare
Sometimes I feel like the difference between a junior, intermediate, and
senior developers is that the junior hasn't yet figured out how to use
regexps, the intermediate dev has, and the senior dev has figured out not to.

I kid, but...really. The number of times I've seen people burnt by non-trivial
regexps in production code is absurd.

"Oh, I need to mangle this CSV that's in the wrong format"? Sure, write a one-
off regexp.

"Hm, there might be a security vulnerability in this URL parameter, I need
some way to filter out bad inputs..." Oh _hell_ no.

Literally two weeks ago I tracked down a crazy bug to a regexp someone had
written to try and correct mistyped email addresses in a signup form (?!) that
deleted "invalid" characters. Like a "+". So many facepalms for one short line
of code...

~~~
anotheryou
out of curiosity: what would you use for the URL validation?

(but i get this is difficult:
[https://gist.github.com/dperini/729294](https://gist.github.com/dperini/729294)
)

~~~
nly
Well, it's clear to see why people are lead astray. In this case, RFC 3986,
which defines what a URI actually is, itself actually proposes a regex[0]. It
even claims, and I quote, 'the "first-match-wins" algorithm is identical to
the "greedy" disambiguation method used by POSIX regular expressions'. Of
course, it doesn't actually _validate_ anything... it just performs
rudimentary field extraction. Trying to do anything beyond that with regex is
madness.

The ABNF grammar is fairly simple though and, I think, free of ambiguities.
I've had luck converting it straight in to PEG form. It's not a trivial or
wholly useful endeavour though, and, if you do so, remember to check the
errata. For HTTP you'll also have to add in the changes from RFC 7230[1].

Oh, and of course, none of this validates DNS names, their labels, etc. for
length, the "LDH rule", or the public suffix list[2], or IP addresses to check
whether they have publicly routable prefixes.

Bottom line is, if you want to validate a URL, the best thing to do, much like
e-mail, is to just try and GET it.

[0]
[https://tools.ietf.org/html/rfc3986#appendix-B](https://tools.ietf.org/html/rfc3986#appendix-B)

[1]
[https://tools.ietf.org/html/rfc7230#section-2.7.1](https://tools.ietf.org/html/rfc7230#section-2.7.1)

[2] [https://publicsuffix.org/](https://publicsuffix.org/)

------
pilif
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()}]+(?<m>[^()]*\((?:\g<m>|[^()]*)\)[^()]*)*[^()]*\)[,]?$
    

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

~~~
jandrese
The worst part is that as soon as he mentioned regular expressions I knew
exactly what the problem was.

Regexes are powerful and useful but also dangerous. People who don't
thoroughly understand them and try to get fancy often run into problems like
this. In general you shouldn't be using them to parse a computer language
anyway, it is something you should be using a tokenizer/parser for.

~~~
kuschku
If something can be done with regex, someone will do it with regex, and it
will end up in a big project.

That’s why I weeped when support for named groups and backmatching was added.

------
josteink
Completely unrelated to the issue at hand... I had no idea Atom was written in
CoffeeScript. I thought it was written in Javascript, which made me positive
at the thought of hacking into it.

But this code? Definitely giving me a headache, and my interest went down to
zero. There seems to be a meme and unchallenged _claim_ in hacker circles that
CoffeeScript is somehow more "readable" and easier to understand.

Allow me to disagree, and I suspect there's quite a few like me. This code is
harder to read. I _think_ I understand what the code does, but I can no longer
be certain about the language semantics. That introduces needless uncertainty.

And it just broke all my pre-configured and pre-setup JS-tooling. Can't use
any of that for this codebase. Just great.

So what's up with people writing applications and projects in NodeJS, a prime
JS-environment which supports "all" modern Ecmascript-features, classes
included, and then decide to go use a non-standard language for their app?

And for what gains? How did Coffeescript make this code more readable or
easier to debug? It didn't. And now you need to debug code compiled from the
actual code you wrote. How does that do anything except make everything
harder?

TLDR: CoffeeScript seems like a bad choice for just about everything and I
can't see why any big project with a desire for contributors would even
consider using it.

~~~
Lazare
First, good news: The Atom teams is (slowly) moving away from Coffeescript
towards modern JS, and I think they'd agree (unofficially) that the choice
proved to be a mistake.

Beyond that...

1\. The JS world moves stupidly fast, and Coffeescript is a relic of a now-
vanished age. It was born, it evolved, and it died. Back in those long ago
days of, um, 5 year years ago, there was no ES6, and Coffeescript looked a lot
more attractive. So much so, in fact, that ES6 stole a bunch of Coffeescripts
better features.

2\. If you're familiar with Coffeescript, it's terse and expressive and very
readable. If you're not, it looks like gibberish. But that's true of _any_
language. The proper critique of Coffeescript should be "hey, not a lot of
potential collaborators know it, so it'll see unreadable _to them_ ", not
"hey, Coffeescript is generally unreadable". JS is pretty confusing and
unreadable if you don't know it too.

Mind you, Atom was released 2 years ago, when Coffeescript was already
starting to look dated. And it was an open source project looking for
contributors so...yeah. Bad, bad choice. :)

~~~
andrewingram
In fairness, I built a fairly large app using CoffeeScript and it still took a
lot of brainpower to read it compared to JS. All the typical complaints about
ambiguous-looking syntax match my experiences exactly.

I ended up with a general workflow of having my Coffeescript source and the
generated JavaScript sitting side-by-side so I could check that the output was
what I was expecting. I've only had the urge to do that with ES6 and Babel a
couple of times.

~~~
Lazare
I built a pretty large app using Coffeescript, and I was about to say that I
disagreed, and never felt like I needed at the generated output, but...

...now that you say that, I did end up going to the Coffeescript REPL on their
website to test a bit of syntax a fair number times. I feel like a got used to
it pretty fast, but I agree, a big chunk of Coffeescript's learning curve is
getting past it's ambiguity, and there were some features I expressly avoided
just because they were too confusing. Eg, I could never remember the
difference between 'in' and 'of' in CS, so I just used underscore's
equivalents. And then there were the comprehensions, and the weird scoping
rules, and...yeah.

I'll be honest, switching from CS to a modern Babel/ES6+ configuration, I
thought I'd really miss CS, but I really haven't. I maintain that if you know
CS, good CS code is easy to understand, but good CS code takes way too much
work to write. :)

~~~
xiaoma
Interesting. Comprehensions are probably the main thing I miss. I liked the
automatic returns and the @ shorthand, but whenever I find myself using Python
for whatever odd reason, having comprehensions again is like encountering a
long lost friend.

------
jeffbr13
Isn't arbitrarily-long nesting or matching any sort of palindrome, where you
count up and down, the classic case of something you should never do with a
regex, because they're _finite_ automata?

People don't build parsers because of masochism, but because regular
expressions are provably insufficient to capture things like nesting. You need
to go at least one level up on the Chomsky hierarchy[1] to pushdown automata
for that.

More importantly, shouldn't SOMEBODY working on a text editor know and
recognise this sort of thing? I'm all for the hacker mentality of shipping,
reducing developer time instead of machine time, using what you know, but this
is the sort of hacky fix that just pushes the problem further down the line.

Great write-up though, very enjoyable read!

~~~
jdmichal
I found this on the ground. Did you drop it?

[1]
[https://en.wikipedia.org/wiki/Chomsky_hierarchy#The_hierarch...](https://en.wikipedia.org/wiki/Chomsky_hierarchy#The_hierarchy)

------
kcbanner
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
quotes here because really that just means "people who know web languages"),
but that goal could still be accomplished in a native application that
embedded a JS runtime for plugins.

[1]: [https://discuss.atom.io/t/high-usage-cpu-and-
memory/16165/3](https://discuss.atom.io/t/high-usage-cpu-and-memory/16165/3)

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

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

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

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

~~~
cyphar
> 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

I think the only thing that Vim doesn't do that it should is actually use a
proper language for scripting. Emacs has elisp, but Vim has VimScript which is
a horribly stunted langauge.

Aside from that, I much prefer vim to emacs. Just because everything is mode-
based, and the keybindings don't require 10 hands to do anything.

~~~
zeveb
Check out spacemacs: the modes of vim, and the extensibility of emacs. Not
really by cup of tea, but it sounds pretty cool.

------
wereHamster
Could be avoided if the editor had a full AST of the code instead of using
regular expressions to try to make sense of it.

~~~
EdiX
The syntax will be broken 99% of the time and making a parser that recovers
gracefully under any circumstance is very hard.

You could make an editor that only allows valid programs but that opens up a
lot of UI problems, it was tried many times and it never took off in practice.

~~~
Kristine1975
Yet Eclipse and IntelliJ IDEA (and most likely a lot of other IDE's)
successfully use AST's for their code editor. The syntax will only be broken
locally, so it's not that hard to recover.

~~~
scotty79
I tried Eclipse many times over last decade. Always used for few weeks before
code highlighting and completion drove me insane due to multiple crashes,
hangups and slowdowns.

Trouble with elaborate 'correct' solutions starts when you need another thing.
I don't think support in Eclipse for .cjsx or PureScript or whatever is coming
soon. I won't wait 10 years till they get it 'right'. I'll use Atom to get the
95% right in few months.

------
zenocon
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 <enter>. It always defaults to the first character of the next
line. It seems insertNewLine somehow is not able to grok the idea of more than
one set of matching brackets.

Edit: issue filed [https://github.com/atom/bracket-
matcher/issues/209](https://github.com/atom/bracket-matcher/issues/209)

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

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

------
spinningarrow
> This defines a named capture group, <m>.

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](http://coffeescript.org/#regexes)).

~~~
fuzionmonkey
[https://github.com/atom/node-oniguruma](https://github.com/atom/node-
oniguruma)

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

------
jeffjose
Ofcourse it was regex. Regular Expressions: Now You Have Two Problems

Good job!

------
sotojuan
I'll admit and thought that by "fixed" he meant made it not start slow... but
this was very well written and interesting. Great job Mr Galbraith!

------
sergiotapia
I wonder if this is why Atom feels so snappy now. It's my main editor as of a
few weeks ago because the speed is now good. It used to choke on a 1000 line
rails controller, but now it edits that file just perfectly.

Congratulations to the author, great commit! Small payload, enormous benefits.

------
jakub_g
It seems there's a need of a regex linter (eslint plugin?) that could warn on
pathologically complex regexes. Is building this kind of plugin feasible?

Having said that, probably few people would explicitly opt in to using such a
plugin unless it's bundled by default to some linter.

~~~
oneeyedpigeon
Well, regex101 [1], linked in the article, detects it, so it's definitely
possible. Whether that code is open, or it's easy to replicate, is another
matter.

[1] [https://regex101.com/](https://regex101.com/)

------
wmonk
While this was a good read, should it not be titled:

# How I fixed the 'atom/language-go' package

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

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

~~~
odbol_
Dude, you don't need to be so semantic. The headline had "atom" in the title,
it had to do with Atom the editor, what more do you want? Do you think every
headline should be excruciatingly specific and exact? Might as well just put
the whole article in the headline.

------
lucaspiller
I haven't worked on Atom or Electron apps (although it's on my todo list), but
does the Chromium debugger not work inside them?

~~~
Klathmon
Yes it does, and that was my biggest annoyance with this article.

The chrome debugger with breakpoints, profilers, and a whole slew of other
goodies is great for this sort of debugging.

Yeah, sometimes i need to avoid it because turning it on can actually slow the
code down significantly, but the profiler would have been perfect to see where
the time was spent here with just a few clicks.

~~~
nacs
> that was my biggest annoyance with this article

Perhaps a core contributor or someone who regularly works on the code-base
would have approached it with the full suite of debugging tools available as
you mention.

However, I get the impression that the author of this article is not one of
those and simply wanted to crack open his editor to fix this one problem he
saw (and happened to learn more about Atom, Coffeescript and regexps along the
way).

Being upset over a great open-source contribution because they used "non-
ideal" methods to arrive at a solution is just silly.

~~~
Klathmon
I probably could have worded it differently, but I'm not upset about it, it
just makes me sad that people might not know that these tools exist!

I often use the same kind of thing for debugging (console.log('got here'))
because it's sometimes too much work to leave the code to just get an
understanding of if something is hit or not.

When i started reading the article i was really hoping he would use the
profiling tools. I just feel sad that they are being overlooked a lot of the
time, and this is a textbook perfect use case for it!

------
zeveb
Yet more proof that anyone who uses regular expressions to attempt to parse a
context-free grammar is in a state of sin.

Balanced parentheses form a context-free grammar, and thus cannot be parsed by
regular expressions. There are extensions to regexps which make them irregular
— and hence capable of parsing CFGs — but they often lead to poor performance,
as here.

------
pmilot
I'm not familiar with the way syntax highlighting and code indentation logic
in text editors is implemented, but using regular expressions to try and parse
a CFG like the Go programming language seems like a phenomenally bad idea.

Maybe everyone does it and everybody is happy with it working only in 90% of
cases, but it just seems like the wrong approach to me.

------
roddux
Nitpick: Why is the link to 'Atom' in the article just a link to a Google
search for 'atom editor'?

~~~
davidvgalbraith
Haha, don't know how that got in there. Fixed it to point to atom.io, thanks
for pointing it out!

------
ousta
Performance wise I never understood why ATOM is even used. it is lackluster
compared to a notepad++ and there is a delay in every action: loading the
software, clicking on a tab, on a menu, on an option. it seems to me like a
very wrong idea to push the web into softwares

~~~
Klathmon
When was the last time you used Atom?

It's definitely not the fastest opening editor, and it does have performance
issues, but they tend to be more rare than common.

The 2 that bite me are:

* the update/install screens in the settings tend to be a bit slow

* opening "large" files that have 1000+ characters per line will either hang or crash the browser depending on the size. If it's a "normal" looking source file, it runs like a dream with files up to 5gb+ (the largest i've used it for), but if it's something like a minified javascript file, a few kb is enough to hang the editor.

Outside of those 2 issues, i don't see any lag or stuttering in my normal use,
and i've got about 70 plugins on top of the defaults.

But to answer your question, it's the customizability and the massive number
of plugins that draws me. Plus it's fucking beautiful, and i know this isn't
the most popular opinion, but if i'm going to stare at this thing for 6+ hours
a day, i want it to look good!

~~~
kungtotte
It's by far the slowest compared to Sublime Text 3 and Visual Studio Code.
VSCode and Atom obviously suffer from being Electron based compared to ST3, so
the comparison there isn't exactly fair, but VSCode is noticeably faster to
load and snappier to work with even loaded up with third party plugins. I have
a similar amount of plugins for each of the three (10-15) too, so no real
difference there.

And honestly I don't see a marked difference in visuals between those three.
After installing my zenburn colour scheme they're virtually identical with
similar if not identical UI features.

I don't expect the Electron based editors to match ST3 for performance (at
least not yet), but honestly it's kind of embarrassing how slow Atom is
compared to VSCode, particularly when it comes to things like checking for
package updates and just _starting up_.

This is all based on using all three editors within the last three months
(I've been swapping around trying to find what I like).

------
alkonaut
The lesson is: don't parse with regexes. At all. Even for a first draft of a
plugin for editor support for some obscure language should regexes be used for
this kind of job.

Surprised to see that mistake in code that otherwise looks pretty high
quality.

------
bproctor
I really really want to love this editor, it's beautiful, but it burns me
every time I use it and I end up going back to sublime text. Slow, buggy,
hangs, 100% cpu usage, huge amounts of memory usage...

------
cliffordfajardo
For those who want a quick look at the state of Atom today & it's packages I
made a video covering the top frontend and backend packages for Atom.
[https://www.youtube.com/watch?v=cFAzqvYoHJs](https://www.youtube.com/watch?v=cFAzqvYoHJs)

Or here's a small blog post I made: [http://cliffordfajardo.com/2016/atom-
editor-review/](http://cliffordfajardo.com/2016/atom-editor-review/)

------
snarkyturtle
You'd think both Atom contributors and the author would make use of
coffeescript's multi-line Regex syntax so they could mark it up with
comments...

------
Tyr42
Grrr, that's not a _Regular_ expression at all. I think you'd be better off
looping over the string and counting the number of ( and )s in a loop,
guaranteed linear time.

I wish people would stop abusing regular expressions.

~~~
GFK_of_xmaspast
A regex is far more useful than a regular expression, and I'm ok with the
terms getting conflated.

------
mohsinr
What a wonderful article! Yes what a nice trip you had to fix awesome editor
(Yeah I am using ATOM and I love to code in it)!

------
limeyx
...and thats why Regexes should usually be avoided :)

------
ajmarsh
Good work. With enough eyeballs all bugs are shallow.

------
diegorbaquero
Wow mate, nice debugging down to the core.

------
andreapaiola
Good job

------
kitwalker12
you sir deserve this [https://xkcd.com/208/](https://xkcd.com/208/)

------
foxhedgehog
getting a 500, which tracks with my experience of atom

------
fenollp
> Having very little to go on, I began the search by searching the whole
> codebase for the word “newline”.

Is this really how people troubleshoot JS issues? In 2016?

~~~
GFK_of_xmaspast
I don't know javascript beyond the most basic aspects, what would you have
suggested here.

~~~
Merad
Start debugger, cause 'freeze' to happen, pause debugger, look at call stack.
I touch JavaScript as little as possible, but that's what I would do in any
decent language.

------
ilaksh
"How I fixed a bug in Atom that affected almost no one, and then spent quite a
lot of time writing an article about it, then wrote a title that attempted to
give me more credit than I deserved"

.. which is his main pass time if you see his other posts, rather than
spending his effort on fixing bugs that actually affect a lot of people. I am
sorry but I don't really appreciate it and have trouble getting over the
misrepresentation in the title of the blog posts.

~~~
jk563
Sure the title is a bit sensationalist, but there was a legitimate issue to
fix and he did fix it.

Plus, it is a good write up that explains the problem, solution, and the steps
taken well.

It would be a shame to see others put off from fixing bugs, and posting
commentary on the solution, in open source software for fear of being put
down.

~~~
ilaksh
Others should be put off from taking more credit than due in the title of
their posts and from taking on bugs that aren't important just for that
purpose.

~~~
oneeyedpigeon
No, _nobody_ should be put off taking on _any bug_. I hugely appreciate the
fact that different people are up for different challenges and, therefore,
with enough people, bugs should be fixable. Your ethos appears to be 'some
bugs are just boring and not important enough; never bother fixing them'.

