steinroe
Joined 6 years ago
Karma
181
Submissions
33
Member since
Jun 27
Recent submissions
Comment · 4 months ago
afaik, you should be able to use named session to achieve this: https://herdr.dev/docs/persistence-remote/
Comment · 4 months ago
i wanted to build a formatter for my postgres language server but always knew i would never have the time for it. when claude code first came out, i gave it a shot, but it was too inconsistent and still needed too much handholding. i retried it again at the beginning of this year. like before, i set up the harness to run overnight, expecting to throw it away the next morning. but nope, it deliberately worked through all the syntax nodes and followed patterns closely enough so that a few hours of my work could make it ready for the pr.
Comment · 1 year ago
I do not have experience with monaco, but you should be able to run the language server remotely and connect to it from the editor via the usual language server protocol.
we currently do not provide a wasm build which would enable us to run the server within the browser too, although that's something I am actively poking around with.
Comment · 1 year ago
we write about this in the blog post, but the tldr is that the Postgres syntax is ever-evolving and very verbose. its almost impossible to properly parse Postgres code in a sustainable way. all these tools usually try to do exactly that and eventually give up. we are building upon libpg_query instead, which is the actual Postgres server code extracted into a C library. that parser is built to parse executable SQL though, so we had to find a few workarounds to make it work.
Comment · 1 year ago
its still in the cards! it will be more like a pretty printer instead of a formatter though. Meaning we will prettify valid code only. but its a bigger effort, and we want to focus on a stable basis first.
Comment · 1 year ago
I did some research on it and afaik, all these tools run their language services as typescript plugins within the tsserver itself. this means they do not communicate to their own language server running next to it. right now, I am thinking to
a. make a wasm build work and then try my luck with the tsserver plugin and
b. enable embedded sql support for typescript in the CLI at least by parsing the code with oxc
Comment · 1 year ago
I learned rust by doing this project. didn't have much prior systems programming experience too. usually, I learn best by just trying things until they work, but building a language server is pretty complex. after reading through a lot of similar projects, biome was the easiest to reason about. and it has exactly the architecture I had in mind: a generic workspace api where the language server is just one of many entry points.
Comment · 1 year ago
that is really awesome! declarative schema management is also high on my bucket list, and might even become part of this project. thanks for sharing, will check it out.
Comment · 1 year ago
thanks for the report! that was an oversight. pr with the fix is up.[0]
[0] https://github.com/supabase-community/postgres-language-serv...
Comment · 1 year ago
its still a bit rough around the edges, but we hope to kaizen our way through based on the bug reports from the community!
about embedded sql: you are right, this must be solved on the editor side. in vscode, it should be possible via request forwarding [0]. for neovim there are plugins like otter.nvim [1].
and at least for js, we are planning to add direct support for it in our workspace api so that `postgrestools check file.ts` will emit diagnostics for embedded sql. this is only feasible because we can easily parse js/ts code in rust via oxc[2] though. are you aware of similar tools in other languages?
[0] https://code.visualstudio.com/api/language-extensions/embedd... [1] https://github.com/jmbuhr/otter.nvim [2] https://oxc.rs
Comment · 1 year ago
to put things into perspective: even though it took a lot of effort, it's just a side project by two people who used it to learn rust along the way. A full-time team would have finished much faster.
Comment · 1 year ago
that's something we are currently looking into for typescript. at first, I thought a tsserver plugin will do. but a bit of research suggested that such a plugin can not call other language servers. this must be solved on the editor side instead. in vscode, it should be possible via request forwarding [0]. for neovim there are plugins like otter.nvim [1].
and at least for js, we are planning to add direct support for it in our workspace api so that e.g. `postgrestools check file.ts` will emit diagnostics for embedded sql.
[0] https://code.visualstudio.com/api/language-extensions/embedd... [1] https://github.com/jmbuhr/otter.nvim
Comment · 1 year ago
thanks for asking! its what provides all language intelligence features in your IDE. so autocompletion, diagnostics, syntax highlighting etc. the postgres language server currently supports autocompletion, syntax error highlighting, type-checking and linting.
Comment · 1 year ago
my pleasure! I had my ide point to the debug build locally for over a year now, and it has been very rewarding to slowly see it mature (as in crash less) during my day job over time.