Hacker News Reader

Comment by crooked-v | Hacker News Reader

What I'd really like is an IDE that functions on objects of code and not text files, and diffs and merges thar similarly operate on the syntax tree of the code and not on whether there's an extra newline or not.

Like, code formatting, that's just an implementation detail. Why can't there be a thing to let two people edit the same repo with different formatting preferences without it causing merge conflicts?

View on HN

Maybe you're already aware of it, but there is difftastic [0], which is a syntax aware diff tool that can also be used with git. Its understanding of syntax is based on treesitter, so it works for most languages. Although I haven't tried, I think most IDEs should also be able to use it.

[0] https://difftastic.wilfred.me.uk/

This is essentially the concept of a "text object" from Vim. Historically, it was somewhat challenging to actually define text objects with the richness of behavior one might want, but now with Tree Sitter and LSP you can have this pretty much for any language or file format.

> and diffs and merges thar similarly operate on the syntax tree of the code and not on whether there's an extra newline or not.

We really lost so much when we moved away from s-expressions in favor of... whatever adhoc stuff we do right now.

I feel that the problem is not text but language design. A great language should be close to a pareto optimum for both human and machine legibility. Most languages are optimized for human familiarity, which is definitely not the most machine readable format and probably not the most human readable (in a platonic sense).

Being more specific, most languages, in my opinion, are far too permissive with whitespace and use too many keywords. The former leads to there being no canonical form of the program text and results in reliance on external formatting tools, when the compiler could be just automatically enforcing canonical formatting rules. The latter makes it hard to distinguish between types of words, which is why it is almost necessary to rely on syntax highlighting.

If each program has a unique canonical form, it would be very hard to beat text based diffing on that form. Lisp is quite good from the diffing perspective but weaker on human legibility (for most humans).

Tooling that enforces strict whitespace/formatting rules is a huge pet peeve of mine. It breaks my iteration flow because I have to stop thinking at whatever abstraction layer I'm working at to deal with the minutiae of formatting. I dislike automatic reformats as well, for much the same reason I hate webpages that jump around after loading. Just let me see the code I'm writing without it whizzing off onto adjacent lines because I'm going back and forth over column limits.

an excess of syntactic sugar leads to cancer of the semicolon.

I think treesitter is getting us closer to this goal. Many programming modes in emacs now support treesitter, allowing syntax-aware movement operations, code folding, etc. Even where modes haven’t been set up, you can call “treesit-explore” I think for any language for which you have a grammar available and get an outline of the nodes.

Hopefully we’ll continue to see adoption in this space, as it makes it much easier to add syntax highlighting and other basic support for new languages, and it makes it so that any new functionality that operates via treesitter should work with minimal modification for any language.

The helix editor [1] allows you to navigate and select code objects, I use Alt-o all the time which expand the current selection to the parent syntax node. As mentioned by sibling comments, there are also a bunch of diff tools that are syntax aware instead of operating on plain text. All of these are backed by tree-sitter.

[1]: https://helix-editor.com/

related to this: I want structural editing for non-lisp languages so I don't have to deal with measly lines of code, but with entire trees and branches.