Hacker News Reader

Comment by pgt | Hacker News Reader

> "I do wish there were an easier way to move in the ]}]})))}-ness of block ends though."

If he means navigating the AST, there is Parinfer: https://shaunlebron.github.io/parinfer/

Paredit / Parinfer ruined other languages for me. It lets you navigate up/down/in/out of the Clojure AST with keyboard commands and mutate those expressions, e.g. "Split" will split open the current data structure you're in: `(a| b)` =Split=> `(a)| (b)`, where | is caret. Join is the inverse, and it works for all data structures.

View on HN

Navigating and manipulating code as a tree, directly in your editor. There is nothing like it.

Going back to code as bunch of carefully arranged ascii chars feels like a regression.

Indeed. The incredibly clumsy way we choose to edit source code has baffled me since I was first acquainted with parinfer. Having to keep the source in the shape of a valid AST almost entirely manually is really annoying.

Check out Ki editor https://ki-editor.org/ — core movements based on AST

Huh, very interesting and obvious in hindsight. What languages/syntaxes does it support though? Parinfer is lucky that it's relatively small amount of syntax, so can work for entire languages with relative ease, but how does Ki Editor work with Rust for example, if it does? Special keybindings per language?

Looks like it’s written in Rust and the examples are also in Rust :) Apparently it supports any language with a tree-sitter parser, which makes sense, tree-sitter is basically made for this.

Hmm, but how does that work in practice? Silly and small example; adding/remove turbofish, is very Rust specific, I can't imagine that to be generalized across all tree-sitter parsers, or I misunderstand how tree-sitter is used here, but how would you add/remove/move around Rust's turbofish for example?

In the blind community, navigation by indent level is pretty popular, no idea why it hasn't caught on anywhere else.

I find it a nice middle ground between the craziness of vim and the slowness of traditional cursor usage.

This is borderline silly, though. It is clumsy to start. But so is walking. As is running. Have you seen people start out on bicycles? What about writing? Talking?

That is to say, all things start out clumsy. And people that are good at it, no longer feel that it is clumsy. Which is why a lot of people that have been working with this for any time just don't think of this much.

Such a strange attitude.

If a tool is clumsy, we try to improve it, that has been the case since the first stone artifacts created a million years ago.

Do you think that the (sort of) tree-based affordances that most modern code editors do support, like autoindentation and brace pairing/enclosing, are silly too? What about some slightly more advanced features, like the AST-based "extend selection" and "move statement up/down" features in JetBrains IDEs?

Or do you think that the status quo just somehow happens to be exactly right and going any further would be silly?

It would be silly strictly for how strongly worded it is. I should also say that there is nothing wrong with being silly. Someone may actually come up with something some day that meaningfully changes us here.

That is, I am not disagreeing that it can be a little bit clunky. But, a lot of the power that experienced users have in reading code is specifically that they have built a bit of automaticity in reading it. That is, the clunky aspects of fixing it is something you pretty much have to do. You just build speed at automatically doing it rapidly.

So, the status quo is to use the helper functions that you want to use. But usually after you get the experience in the clunky phase.

Syntax-directed editors were all the rage in the late 70s early 80s...and a huge failure, because they were a lot more annoying than any text editor has a chance of ever being.

It's one of those things that, like visual programming, is absolutely and obviously The Right Thing™ until you try to implement it and use it.

That said, we have made progress in both areas, and maybe we will figure them out in the future.

Yes, it’s definitely not a trivial problem. But parinfer shows it can be done mostly non-annoyingly at least for lisp; what is less clear is whether it would generalize to languages with more syntax.

I type out nowhere near enough code for this to matter, but it's pretty cool nonetheless!

Reply on news.ycombinator.com