Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
maxbrunsfeld
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
11 ms
·
61.
▲
by
maxbrunsfeld
8y ago
Good question. At one time, I had the thought that folks who disliked JavaScript might want to write their own grammar DSL in another language, which could generate compatible JSON to be consumed by the core Tree-sitter compiler library. No
62.
▲
by
maxbrunsfeld
8y ago
It's not actually implemented as a scannerless parser, but the grammar API mostly abstracts away the parser/lexer distinction. We have to handle JSX and all language versions combined because for our use case, users need to be abl
63.
▲
by
maxbrunsfeld
8y ago
Hey, author of Tree-sitter here. Thanks for sharing this! I'd be happy to answer any questions people have about the project.
64.
▲
by
maxbrunsfeld
8y ago
The GIF is just intended to represent an idea - that parsing (for the purpose of syntax highlighting and other code analysis) can no longer impact the app's frame rate, because it has been offloaded onto a background thread. The actual
65.
▲
Atom 1.29
(blog.atom.io)
7 points
by
maxbrunsfeld
8y ago
|
1 comments
66.
▲
by
maxbrunsfeld
8y ago
Animals don't raise other animals on cruel factory farms.
67.
▲
by
maxbrunsfeld
8y ago
There's a button to toggle whether these lines are shown or hidden. Implementing this button's behavior using JavaScript seems perfectly reasonable to me.
68.
▲
Atom 1.28
(blog.atom.io)
139 points
by
maxbrunsfeld
8y ago
|
110 comments
69.
▲
by
maxbrunsfeld
8y ago
GitHub has helped to maintain git itself for years, in addition to creating and open-sourcing libgit2, a massive engineering effort, which ironically, GitLab is built on.
70.
▲
by
maxbrunsfeld
8y ago
I’ve locked a helmet up with my bike all my life, in several different cities; It’s a complete non issue to me. What is the concern; that someone will use a blade to cut the helmet strap so that they can steal your broken helmet? It’s effor
71.
▲
Atom 1.24
(blog.atom.io)
15 points
by
maxbrunsfeld
9y ago
|
1 comments
72.
▲
by
maxbrunsfeld
9y ago
The protocol isn't coupled to the DOM or Electron in any way. The one thing that makes it easier to implement in electron is that it uses the WebRTC standard for peer to peer connections.
73.
▲
by
maxbrunsfeld
9y ago
Do you remember if there was an issue opened for this on the Atom repo? I haven't heard of this problem.
74.
▲
by
maxbrunsfeld
9y ago
Thanks! Yeah all of the CoffeeScript in atom/atom should be gone in a few months probably. We use plain JS now. It'll probably take a while before there's no more CoffeeScript in the entire Atom org . We're gradually co
75.
▲
by
maxbrunsfeld
9y ago
I really want to create a public-facing roadmap that's specific to this issue. Unfortunately, our resources are limited so we often don't focus enough on blogging/publicizing our planning... but in the meantime, here's s
76.
▲
by
maxbrunsfeld
9y ago
You really aren't. Atom runs fine on a Macbook Air. There are definitely performance issues, but we're addressing them; it's just that our team is small and our initial goal at launch was to produce the most hackable text e
77.
▲
by
maxbrunsfeld
9y ago
Sorry to hear that. We’re improving Atom’s efficiency all the time, but there are definitely areas that we just haven’t gotten to yet.
78.
▲
by
maxbrunsfeld
9y ago
Thanks for the really concise example.
79.
▲
by
maxbrunsfeld
9y ago
We are already able to run native code in Atom via node's native extensions, so we have no reason to wait for WebAssembly. The only benefit of WebAssembly would be if we wanted to port Atom to work in a regular web browser. We can even
80.
▲
by
maxbrunsfeld
9y ago
I don’t know how you could read this post and not get this: The Atom team is quite capable of writing C++. It’s not painful at all. I love writing low level data structures in C++. It just wouldn’t be an improvement for the vast majority of
81.
▲
by
maxbrunsfeld
9y ago
PCRE's partial match[0] API allows it to be used on non-contiguous data structures. We use this feature in Atom[1] to allow for fast regex search in a background thread. [0] http://www.pcre.org/original/doc/ht
82.
▲
by
maxbrunsfeld
9y ago
Atom uses a piece-table-inspired data structure to represent text[0]. We store the file's original contents in a single contiguous buffer. All of the user's unsaved edits are then stored in a separate mutable structure called a Pa
83.
▲
by
maxbrunsfeld
9y ago
That's one good reason that you might choose to use Electron, but it's not the main reason that Atom uses it. One of the main goals of Atom is to be the most hackable text editor ever. Given that goal, Electron is the ideal plat
84.
▲
by
maxbrunsfeld
9y ago
Atom has always had some C++ components, but lately we have moved more core data structures to C++. This PR, which re-implements the text-buffer in C++, also landed in the latest beta. https://github.com/atom/atom/
85.
▲
by
maxbrunsfeld
10y ago
FWIW, I'm developing a library based on the technique outlined in this paper (and others by Time Wagner). Like the original paper, it uses LR(1) (and GLR), not LL(k). The library itself is here: https://github.com/tree-
86.
▲
by
maxbrunsfeld
10y ago
This is a parser generator that I'm working on: https://github.com/tree-sitter/tree-sitter It produces concrete syntax trees that can be queried by line or character index. The library is specifically focused on
87.
▲
by
maxbrunsfeld
10y ago
How would a gap buffer handle distributed editing operations like search-and-replace, or multi-cursor typing? The data structure seems optimized for editing in one place at a time.
88.
▲
by
maxbrunsfeld
10y ago
Is this on 1.14-beta0? If so, please open an issue. We now do a lot of text layout computation lazily, but currently, it's very easy for a third-party package to accidentally force the entire text layout to be computed immediately via
89.
▲
by
maxbrunsfeld
10y ago
I'm curious about why higher-kinded types are needed for this. I'd have thought that it would be possible to create these kinds of traits in rust's current type system. Is there someplace I could read more explanation on this
90.
▲
by
maxbrunsfeld
10y ago
> CYK and Early parsers are both actually simpler than parsing with derivatives, once you've thrown this paper's optimizations in. Yeah, GLR is very elegant as well; I'm a little puzzled by this paper's initial claim
More ›