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

61–70 of 189 posts

Re: How I fixed a bug in Atom

#61

Post by scotty79 »

Kristine1975 wrote: post #54
EdiX wrote: post #22

Earlier quoted context omitted.

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.

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.

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.

Re: How I fixed a bug in Atom

#62

Post by anton_gogolev »

anotheryou wrote: post #59
Lazare wrote: post #45

Earlier quoted context omitted.

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…

out of curiosity: what would you use for the URL validation? (but i get this is difficult: https://gist.github.com/dperini/729294 )

I prefer straight up imperative code (or, better yet, whatever Url/Uri API that is provided by the platform).

Re: How I fixed a bug in Atom

#63

Post by toomanybeersies »

Grue3 wrote: post #50
mjmasn wrote: post #26

Earlier quoted context omitted.

Just tried this, you are correct... http://imgur.com/J9tP7lk (note the incorrect bracket highlighting)

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

Apparently that's easier said than done.

Re: How I fixed a bug in Atom

#64

Post by EdiX »

Kristine1975 wrote: post #54
EdiX wrote: post #22

Earlier quoted context omitted.

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.

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.

I said it's very hard not that it's impossible. If you think it's easy write a parser with recovery for every language Atom supports.

Re: How I fixed a bug in Atom

#65

Post by Lazare »

andrewingram wrote: post #53
Lazare wrote: post #44

Earlier quoted context omitted.

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

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

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. :)

Re: How I fixed a bug in Atom

#66

Post by 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 . 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

Re: How I fixed a bug in Atom

#69

Post by barrkel »

EdiX wrote: post #22
wereHamster wrote: post #7

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.

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.

It doesn't need a full AST. It needs a tokenizer and a nesting level or potentially a stack of different classes of token nesting.

This parser would not be difficult to write; the only "recovery" is in choosing how to react to mismatched token pairs. The simplified problem means heuristics could potentially be used.

Re: How I fixed a bug in Atom

#70

Post by zamalek »

cyphar wrote: post #10

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…

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

Post reply on HN