A Better R Programming Experience Thanks to Tree-sitter
Posted by sebg 17 hours ago
Comments
Comment by tylermw 12 hours ago
I wrote a VS Code extension that analyzes the pipeline and provides useful hover information (like size, time last invalidated, computation time for that target, and children/parent info) as well as links to quickly jump to different targets and their children/parents. I've dogfooded the hell out of it and it's already vastly improved my targets workflow within a week. Things like providing better error hints in the IDE for targets-specific malformed inputs and showing which targets are emitting errors really take lots of the friction out of an analysis.
All that to say: nice work on extending tree-sitter to R!
tarborist: targets + tree-sitter https://open-vsx.org/extension/tylermorganwall/tarborist
Comment by kqr 7 hours ago
Comment by CrazyStat 3 hours ago
The old fashioned way to do this in R is to use the REPL and only rerun the lines of the script that have changed, with the earlier part staying in the environment. But it's easy to make mistakes doing it manually that way; having the computer track what has changed and needs to be rerun is much less error-prone.
Comment by tylermw 59 minutes ago
Comment by adamalt 5 hours ago
Comment by davisvaughan 2 hours ago
Comment by tylermw 1 hour ago
Comment by nomilk 14 hours ago
R/RStudio was my first language/IDE. I was horribly shocked when moving into other languages to discover they didn't have things you got out of the box with R/RStudio. "You mean I have to look up documentation for a function/method!?! - that's supposed to be automatic!".
R has a bunch of features which other languages lack to the degree that it's a rude shock to learn that other ecosystems lack them. One is the REPL with extremely convenient RStudio keyboard shortcuts to run lines of code (to achieve similar with ruby, I have an elaborate neovim/slime setup that took hours to configure and still isn't as good as RStudio gives out of the box).
A sign of a brilliant tool is when an idiot can get more done with it than an expert can with alternatives.
Comment by mscbuck 3 hours ago
Comment by chocochunks 2 hours ago
Comment by MostlyStable 14 hours ago
So either this is not that exciting, or else the additional things that are on offer are not very clearly explained to the point that I missed them.
Comment by nomilk 13 hours ago
Looks like R's tree-sitter grammar has been in use for GitHub search for a while (since 2024), so it's a nice improvement due to R/tree-sitter, although we've probably been benefitting from it for a while already, perhaps without knowing exactly how it worked!
https://github.com/orgs/community/discussions/120397#discuss...
Comment by user3939382 12 hours ago
Comment by kqr 7 hours ago
(The n×m problem is that for n languages and m tools like autoformatting, etc., we need an implementation for each tool specific to each language. With tree-sitter, we get n+m implementations instead: generic tools that work across multiple languages.)
Comment by stephbook 9 hours ago
- Merge request on GitHub - Presentation with reveal.js (kind of like PowerPoint)
You'd be stuck with either bland, uncoloured, text-only characters, OR with a fuzzy PNG screenshot where you can't zoom or copy. Or maybe you "parse R" with Regex.
tree-sitter integrates into any web-based technology, allowing you to _share_ code.
Comment by nomilk 9 hours ago
Comment by epistasis 15 hours ago
Comment by sundarurfriend 3 hours ago
Comment by dash2 7 hours ago
Is there any interest in this? There are per-language complexities, for example R functions are often preceded by a roxygen block which ought to travel with it. Has anyone done something similar?
Comment by tylermw 56 minutes ago
https://bsky.app/profile/tylermw.com/post/3mjmcykuows2d
So yes, it is possible and quite useful!
Comment by mscbuck 3 hours ago
Comment by fn-mote 14 hours ago
Comment by moffkalast 5 hours ago
Comment by mscbuck 3 hours ago
Comment by sieste 2 hours ago
Comment by TacticalCoder 14 hours ago
I had a first little use case... For whatever reason the options to align let bindings in Clojure code, no matter if I tried the "semantic" or Tonsky's semi-standard way of formatting Clojure code (several tools adopted Tonsky's suggestion) and no matter which option/knob I turned on, I couldn't align like I wanted.
I really, really, really hate the pure horrible chaos of this:
(let [abc (+ a 2)
d (inc b)
vwxyz (+ abc d)]
...
But I love the perfection of this [1]: (let [abc (+ a 2)
d (inc b)
vwxyz (+ abc d)]
...
And the cljfmt is pretty agnostic about it: I can both use cljfmt from Emacs and have a hook forcing cljfmt and it'll align everything but it won't mess with those nice vertical alignments.Now, I know, I know: it is supposed to work directly from cljfmt but many options are, still in the latest version, labelled as experimental and I simply couldn't make it work on my setup, no matter which knob I turned on.
So what did I do? Claude Code CLI, tree-sitter, and three elisp functions.
And I added my own vertical indenting to Clojure let bindings. And it's compatible with cljfmt (as in: if I run cljfmt it doesn't remove my vertical alignments).
I'd say the tree-sitter syntax tree is incredibly verbose (and has to be) but it's not that hard to use tree-sitter.
P.S: and I'm not alone in liking this kind of alignment and, no, we're not receptive to the "but then you modify one line and several lines are detected as modified". And we're less receptive by the day now that we begin to had tools like diff'ing tools that are indentation-agnostic and only do AST diffs.
Comment by eviks 11 hours ago
And the first +/inc in parenthesis?