Good work. With enough eyeballs all bugs are shallow.
How I fixed a bug in Atom
131–140 of 189 posts
Re: How I fixed a bug in Atom
#132The 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.
Re: How I fixed a bug in Atom
#133I 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 progra…
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.
Re: How I fixed a bug in Atom
#134Earlier quoted context omitted.
The issue seems to be that Atom uses regular expressions as part of the internal API it uses to separate Atom core from add-on modules.
Maybe the API needs to be changed to allow the module to return a function. After all, JS has first-class functions, so this would make total sense.
This. With a default implementation that falls back to current behavior.
Re: How I fixed a bug in Atom
#135Earlier quoted context omitted.
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…
"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…
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?
Re: How I fixed a bug in Atom
#136Earlier quoted context omitted.
I strongly doubt the AST would be needed. You could probably do this in a trivial loop state machine. It can't even be called laziness: that regex took time to work out - far longer than a switch-based state machine would have taken to write in the first place. Aside: out of curiosity it would have been interesting to see how a Thompson NFA[1] would have dealt with this. [1]: https://swtch.com/~rsc/regexp/regexp1.htm…
> Aside: out of curiosity it would have been interesting to see how a Thompson NFA[1] would have dealt with this. It wouldn't have dealt with it right? NFAs and DFAs are equivalent and them being actually regular means they can't do things like count parentheses.
I miscommunicated the question: "how well would have a Thompson NFA have dealt with this?" I.e. How many magnitudes of order faster would it have been? If it was faster?
Re: How I fixed a bug in Atom
#137Yet 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.
Re: How I fixed a bug in Atom
#138I 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…
Personal reason #1: I can install packages and everything works the first time.
Sublime Text almost had it.
Emacs/vim takes too much effort to configure.
Re: How I fixed a bug in Atom
#139First 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…
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…
> I don't always want to spend insane amounts of time writing full AST parsers.
Then don't use languages whose grammars require insane amounts of effort to parse.
One can write a decent S-expression parser in an hour or two, and a full parser in a weekend. S-expressions can represent everything anyone ever needs to work with, so why use anything else?
Re: How I fixed a bug in Atom
#140Here'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.