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

81–90 of 189 posts

Re: How I fixed a bug in Atom

#81

Post by mbrock »

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.

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.

Re: How I fixed a bug in Atom

#82

Post by mbrock »

zamalek wrote: post #72
toomanybeersies wrote: post #63

Earlier quoted context omitted.

Apparently that's easier said than done.

... with regex.

With anything less than a full-featured lexer and parser of the latest edition of the language in question, I'd say. Including understanding of whatever metaprogramming features or preprocessors that are in play.

Re: How I fixed a bug in Atom

#83

Post by masklinn »

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.

> 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 externally available as a convenient API. ALAS, that's rarely the case, even less so for fast parsing machinery which doesn't throw the information you need for syntactic coloration out the window.

Re: How I fixed a bug in Atom

#84

Post by lorenzhs »

zamalek wrote: post #76
lorenzhs wrote: post #52

Earlier quoted context omitted.

Fun with automata: Constructing the minimal DFA for a given NFA is PSPACE-hard. There are families of NFAs with n states so that the powerset automaton has 2^n states, but the minimal DFA has 1 state. Example: Let Σ={a,b} be the alphabet, Q={q1, ..., qn} be the states. q1 has a self-loop with both a and b and a transition to q2 with a. q2 to q(n-1) have transitions with a and b to the next state (q2 -> q3 etc). qn ha…

> Constructing the minimal DFA for a given NFA is PSPACE-hard. This isn't really a problem if you incur that cost only once by having the regex compiled when the script is parsed. However, idiomatic JS usually includes regex literals in the closure where it is used - decreasing performance, code reuse and clarity. Why? Probably for the same reasons that regex is being used in the first place.

Well, PSPACE-hard is pretty damn hard, so this really depends on the size and complexity of your NFA ;) Of course most of the time you don't hit the pathological cases like the one I described above. My comment was not meant to provide a guideline on how to fix this, consider it a fun observation on automata theory.

Re: How I fixed a bug in Atom

#85

Post by Klathmon »

ousta wrote: post #58

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

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!

Re: How I fixed a bug in Atom

#86

Post by mbrock »

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…

The issue tracker for js2-mode illustrates that such a parsing approach is no guarantee of real-world accuracy either.

https://github.com/mooz/js2-mode/issues

The goal just shifts from having a semi-accurate regexp tokenizer, to having the language mode's complex parser match the complex parser of the language it targets—which will pretty much never happen, unless the language is exquisitely simple, like maybe restricted dialects of Scheme... or Brainfuck.

Re: How I fixed a bug in Atom

#87

Post by issaria »

TazeTSchnitzel wrote: post #55
josteink wrote: post #40

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…

CoffeeScript is supposed to be this nice Ruby/Python-esque sugar for JS. It does resemble those languages, but it's not nice, it's very... stabby. Indentation is unintuitive and makes code do completely different things (whereas in Python it just delimits blocks, and if you get it wrong the compiler will moan at you). Functions implicitly return the last value they produce. You can omit brackets in function calls - b…

Coffeescript is not perfect, however, nowadays people went crazy for ES6/ES2015, and suddenly nobody complains readability of babel output.

I've worked with both, ES6 is definitely a big progress on Coffeescript, but it takes like 80% of the things from coffee IMO, except the indentation syntax and list comprehension, added an `import` keyword.

My point is: don't complain about coffeescript while cheer at ES6, they are mostly the same.

Re: How I fixed a bug in Atom

#88

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

Re: How I fixed a bug in Atom

#89

Post by xiaoma »

Lazare wrote: post #65
andrewingram wrote: post #53

Earlier quoted context omitted.

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

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.

Re: How I fixed a bug in Atom

#90

Post by jordache »

ousta wrote: post #58

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

notepad++'s search feature can not be matched by any other text editor I've come across. I love the intuitive search result window, the direct link to the source document....
Post reply on HN