How I fixed a bug in Atom

Post by softawre » Fri, Jan 29, 2016, 3:00 PM UTC

masklinn wrote: post #83

mbrock wrote: post #81

Earlier quoted context omitted.

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.

> I've never used a language mode that worked properly in all cases. You need a full parser for that to happen, most mode authors don't bother[0]. JS2-mode ( https://github.com/mooz/js2-mode/ ) does that (or attempts to). Most syntactic colorisers are souped-up tokenisers, not actual parsers. It suffices in 99% of cases, but breaks badly elsewhere. [0] it would help if more languages made fast parsing machinery exter…

Post by mannykannot » Fri, Jan 29, 2016, 3:03 PM UTC

thaumasiotes wrote: post #35

reacweb wrote: post #27

Earlier quoted context omitted.

The support of fancy features like backtracking does not cause any degradation of performance for simple regular expressions. You are not obliged to use them, but they do not hurt you when you do not use them. Some other people may love them despite their poor complexity.

Actually, this is false. A lot of regex implementations use a backtracking approach in all cases, causing pathological behavior even on regexes which match a regular language (and so should never take any significant amount of time to process). See https://swtch.com/~rsc/regexp/regexp1.html , which gives a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?a?aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (see the backtracking?…

Post by nv-vn » Fri, Jan 29, 2016, 3:13 PM UTC

masklinn wrote: post #83

mbrock wrote: post #81

Earlier quoted context omitted.

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.

> I've never used a language mode that worked properly in all cases. You need a full parser for that to happen, most mode authors don't bother[0]. JS2-mode ( https://github.com/mooz/js2-mode/ ) does that (or attempts to). Most syntactic colorisers are souped-up tokenisers, not actual parsers. It suffices in 99% of cases, but breaks badly elsewhere. [0] it would help if more languages made fast parsing machinery exter…

Post by HeXetic » Fri, Jan 29, 2016, 3:18 PM UTC

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

Post by [deleted] » Fri, Jan 29, 2016, 3:37 PM UTC

Lazare wrote: post #45

viraptor wrote: post #17

Earlier quoted context omitted.

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)

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…