[HN Gopher] Postgres Language Server
___________________________________________________________________
Postgres Language Server
hey HN. this is a Language Server[0] designed specifically for
Postgres. A language server adds features to IDEs (VSCode, NeoVim,
etc) - features like auto-complete, go-to-definition, or
documentation on hover, etc. there have been previous attempts at
adding Postgres support to code editors. usually these attempts
implement a generic SQL parser and then offer various "flavours" of
SQL. This attempt is different because it uses the actual Postgres
parser to do the heavy-lifting. This is done via libg_query, an
excellent C library for accessing the PostgreSQL parser outside of
the server. We feel this is a better approach because it gives
developers 100% confidence in the parser, and it allows us to keep
up with the rapid development of Postgres. this is still in early
development, and mostly useful for testers/collaborators. the
majority of work is still ahead, but we've verified that the
approach works. we're making it public now so that we can develop
it in the open with input from the community. a lot of the credit
belongs to pganalyze[1] for their work on libpg_query, and to
psteinroe (https://github.com/psteinroe) who the creator and
maintainer. [0] LSP: https://microsoft.github.io/language-server-
protocol/ [1] pganalyze: https://pganalyze.com/
Author : kiwicopple
Score : 751 points
Date : 2023-08-06 10:26 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| timcobb wrote:
| > A Language Server for Postgres. Not SQL with flavors, just
| Postgres.
|
| My heroes, thank you for working on this.
| Exuma wrote:
| Can you try to get it added to Mason so people don't have to try
| and do a custom install?
|
| https://github.com/mason-org/mason-registry/
| steinroe wrote:
| I will add it to mason once it's in an usable state. Feel free
| to open a discussion or issue to keep track of the lsp
| registries.
| iddan wrote:
| This is amazing. I've been using DataGrip for working with
| Postgres in the past year and a half but I would much instead use
| VSCode for complex queries. I love how DB languages become more
| and more first-class citizens in the editor and LSP worlds
| instead of a special type of language with specialised tooling.
| steinroe wrote:
| agreed! especially for smaller teams and startups it can make a
| lot of sense to push more logic in the database, and I hope to
| make this a bit more approachable with this project.
| nonethewiser wrote:
| The vscode-postgres extension is pretty good for crafting
| queries.
|
| https://github.com/Borvik/vscode-postgres
| mkl wrote:
| > Optionated Code Formatting
|
| "Optionated"? Opinionated or optional? Or both?
| rizky05 wrote:
| [dead]
| kiwicopple wrote:
| sorry, I believe Philipp meant that you can "configure it" -
| similar to Prettier:
| https://prettier.io/docs/en/configuration.html
|
| I've updated the Readme
| gfody wrote:
| I liked "optionated" it's like opinionated but with BYO
| opinions
| koolba wrote:
| Does it connect to your actual database as well to get the list
| of tables, columns, etc? Or just leverage the same code base to
| be able to parse the raw text without any data dictionary
| information into a parse tree?
| kiwicopple wrote:
| it leverages your code-base, rather than connecting to your
| database. it uses to libpg_query
| (https://github.com/pganalyze/libpg_query) to construct the
| syntax tree which can then be used to for the LSP features
| continuational wrote:
| Ah, does that mean autocompletion for fields is off the
| table?
| steinroe wrote:
| It will definitely be supported at some point. We will have
| some features that require a db connection, eg
| autocompletion or code actions such as ,,Execute the
| current statement". But always as an opt in.
| [deleted]
| TekMol wrote:
| I am confused what this does.
|
| Is it that I type in my IDE "SEL" and is suggests "SELECT"?
|
| In which situation would this be useful?
| Hendrikto wrote:
| Essentially, LSPs are generic implementations of features like
| autocomplete, expand selection, refactor, etc., with a
| standardized API.
|
| Different editors and IDEs can use the same LSP, without the
| need to reinvent/reimplement the wheel.
| kiwicopple wrote:
| it would also be able to suggest columns/fields from your
| database, as well as picking up errors. for example, given this
| table: create table profiles ( id
| serial primary key, first_name text,
| last_name text );
|
| and this query: select id, firstname from
| profiles;
|
| it would then help to detect if you had an error in your select
| query (in this case, "firstname" should be "first_name"), and
| your code editor would show a warning, even before you try to
| run the code inside your database
| lovasoa wrote:
| I don't think it connects to a database, so it cannot suggest
| field names yet. Correct me if I'm wrong.
| steinroe wrote:
| not yet, but we will add this. As of now, the project is
| just a poc to show that the approach of using libg_query to
| parse the source works. Most of the work is still ahead.
| peter_l_downs wrote:
| Out of curiosity, how has it been working with the pganalyze
| team? It seems like Supabase has been able to collaborate really
| effectively with other teams in the Postgres space (including
| pgAdmin and pgmigra, for the `diff` migrations tooling), and it's
| wonderful to see!
| kiwicopple wrote:
| actually I forgot to mention this one to Lukas in all the chaos
| leading up to our Launch Week. I will do it now
|
| we talked in the past about using their library to extend some
| of Dan Lynch's work (https://github.com/pyramation/postgres-
| ast-deparser) to create a sort of "postgres package registry"
| with dynamic DDL introspection. No progress on that one yet,
| but I'm hopeful that we'll find the bandwidth for it one day.
| peferron wrote:
| > It seems like Supabase has been able to collaborate really
| effectively with other teams in the Postgres space (including
| pgAdmin and pgmigra, for the `diff` migrations tooling)
|
| I'm thankful to Supabase for their efforts, but I'm not sure
| I'd pick pgAdmin and migra as examples of "really effective"
| collaboration with other teams: as far as I know, pgAdmin's CLI
| feature wasn't merged upstream and sits in an outdated Supabase
| fork of pgAdmin which doesn't fully support Postgres 15, and
| migra (which has been abandoned for a while) was just used as-
| is.
| kiwicopple wrote:
| fwiw, pgadmin was not for a lack of trying:
| https://redmine.postgresql.org/issues/6304. I won't have many
| details about migra form the CLI team until they come online,
| but no doubt we'll pick up the migra support if it has been
| abandoned.
|
| (but I agree with the sentiment: we can always find ways to
| be more collaborative)
| srivmutk wrote:
| Always wondered why something like this wasn't made earlier.
| Either way I'm happy that it's being made now, writing SQL in an
| IDE like this should be easier
| psibi wrote:
| This looks nice!
|
| As someone interested in developing a client for it, I'm
| interested in couple of things: what are the features supported
| by it currently, the tweak-able configuration that can be passed
| to it and the various code action available. I like the way nil
| language server has documented it
| (https://github.com/oxalica/nil/tree/main/docs). Is there
| something equivalent available for this ?
| kiwicopple wrote:
| it's very much still a "POC" to verify that the libpg_query
| approach works - perhaps I should have made that more clear
| from the description. We have a PR open which adds source code
| generation to the Rust crate which is close to merging.
|
| your comment is useful and why we submitted this to ShowHN -
| it's easier to get these sort of early feature requests than in
| 3 months once we've implemented more functionality. I'll drop a
| note in GitHub Discussions to investigate the Nil approach.
| michaelcampbell wrote:
| > Not SQL with flavors, just Postgres.
|
| I like the focus on this.
| Wonnk13 wrote:
| would love to take this for a spin in Emacs. I always lsp support
| for sql was lacking.
| lfittl wrote:
| Excited to see this - and excellent use case for libpg_query (I'm
| the original author and still help maintain it together with the
| rest of the team) and appreciate the shout out to pganalyze!
|
| If anyone else has a use case for using the Postgres parser
| outside the server, we have a healthy ecosystem of libraries that
| build on the core C library (we maintain bindings for Ruby, Go
| and Rust ourselves), as well as various projects using it (e.g.
| sqlc uses it for a type-safe way for using hand-written SQL in
| Go): https://github.com/pganalyze/libpg_query#resources
| derefr wrote:
| With all the various systems making use of Postgres's parser,
| is there a reason that the Postgres team haven't "seen the
| writing on the wall" about the demand for their parser, and so
| extracted their parser into a standalone library?
|
| I imagine that Postgres itself would then consume the parser
| library as a -- possibly regularly-snapshot-vendored -- static
| library dependency; while other applications and wrapper
| libraries would be free to consume it as a dynamic shared
| library; and it could be freely independently distro-packaged;
| and so forth. In other words, it would become a de-facto
| "libxml for SQL" -- the kind of venerable C lib that you expect
| everything else to just be a wrapper around.
|
| Is it just that doing this would involve making functions with
| internal linkage into functions with external linkage, and
| thereby preventing some WPO opportunities when compiling
| Postgres itself?
| lfittl wrote:
| Generally I agree that this would be great to have, and
| Postgres does have a set of libraries it already maintains as
| part of the main source tree (i.e. libpq, etc), and there is
| a shared set of code between the backend and the "frontend" (
| https://github.com/postgres/postgres/tree/master/src/common).
| So theoretically you could imagine the parser moving into
| that shared code portion, sharing code but not necessarily
| requiring linking to a library from the backend.
|
| However, the challenge from what I've understood from past
| conversations with some folks working on Postgres core is
| that the parser is currently heavily tied into the backend -
| note the parser isn't just the scan.l/gram.y file, but also
| the raw parse node structs that it outputs. You can see how
| many files we pull in from the main tree that are prefixed
| with "src_backend": https://github.com/pganalyze/libpg_query/
| tree/15-latest/src/...
|
| Further, there isn't a canonical way to output node trees
| into a text format today in core, besides the rather hard to
| work with output of debug_print_parse - there have been
| discussions on -hackers to potentially utilize JSON here,
| which may make this a bit easier. Note that in libpg_query we
| currently use Protobuf (but used to use JSON), which does
| have the benefit of getting auto-generated structs in the
| language bindings - but Protobuf is not used in core Postgres
| at all today.
|
| All in all, I think there is some upstream interest, but its
| not clear that this is a good idea from a maintainability
| perspective.
| lovasoa wrote:
| I am very curious to see how it develops. I'm currently working
| on multiple SQLPage [1] websites, and getting a better IDE
| experience would be awesome. Writing only SQL is refreshing
| compared to all the boilerplate required in traditional web dev,
| but the developer experience is not yet as polished as in, let's
| say, typescript.
|
| [1] https://sql.ophir.dev
| steinroe wrote:
| this is exactly the reason why I started this project. every
| singe line of code is business logic if you write parts of your
| backend directly within the database. plus zero latency and no
| extra servers. I want to make this approach more accessible
| with this project.
| isodev wrote:
| This is very cool! Does it also support extensions? For example,
| would it be aware of additional functions and handling of
| geometries if PostGIS is installed?
| kiwicopple wrote:
| that's theoretically possible, but beyond the scope of the work
| we have planned in the near feature.
|
| it's a great idea though - I will add it to the "Discussions"
| to track for the future. I can personally see the benefit of
| PostGIS support
| yard2010 wrote:
| Are you looking for contributions? Can I join the party?
| kiwicopple wrote:
| yes, we'd love more contributors
| ptrwis wrote:
| I also wanted to ask about extensions. How does it work
| internally? Does it ask the database for parsing or does it
| have its own syntax analyzer?
| steinroe wrote:
| we are using the actual Postgres server source to parse the
| sql file(s) into both an abstract- and a concrete syntax
| tree. Its bundled with the language server and therefore
| works standalone. We will add the option to connect to a
| database, but only to enable features such as
| autocompletion and code actions a la ,,Execute the
| statement under the cursor".
| dgdosen wrote:
| This should work fine with vim-dadbod and vim-dadbod-ui... Right?
| codeptualize wrote:
| Letss gooo!! Supabase keeps on delivering things that I need.
|
| I am regularly surprised how bad the tooling is for
| SQL/databases. Especially that there is no decent formatter that
| supports plpgsql, and doesn't absolutely mangle your queries
| (sometimes actually breaking your queries..).
|
| Best options atm are imo TablePlus and DataGrip, I have tried a
| bunch of options in vscode and although there are useful tools,
| it's all not really there.
|
| (Also excited to see what else they will release this launch
| week!)
| mbork_pl wrote:
| > I am regularly surprised how bad the tooling is for
| SQL/databases.
|
| This. I'd really like to have a _working_ SQL pretty printer
| /formatter. Psql is _great_ , but lacks autocompletion in
| several places.
|
| That said, a big shoutout to pspg
| (https://github.com/okbob/pspg) - an excellent pager for psql
| (also for general csvs).
| cpursley wrote:
| Agree, would love to see this built into TablePlus.
|
| What I really want is a state-based way to define my database.
| EdgeDB & Prism have made some progress here but they really
| only handle table changes. Really wish this were built into
| Postgres somehow (or any solid migration story).
|
| I want to be able to define my tables, views, functions and
| everything and the engine behind it automatically figures out
| all the necessary changes. For example, change a table (add a
| column or something) and it is smart enough to update any
| dependent views and functions. Including handling of data
| migrations.
| codeptualize wrote:
| Supabase cli has a decent diffing option to generate
| migrations (not sure what they use, but it's open source), it
| works quite decent for schema changes.
|
| Not as advanced as you describe though, it won't handle your
| data migrations.
| kiwicopple wrote:
| fwiw, I personally am interested in this approach too[0]. I
| keep running into roadblocks around the ordering of events
| and some of the hairy issues around "destructive" actions
| (eg: renaming columns). i think we can get there, especially
| once we make progress with this LSP.
|
| There are other notable mentions in this space:
|
| Reshape: https://fabianlindfors.se/blog/schema-migrations-in-
| postgres...
|
| Atlas: https://atlasgo.io/
|
| A "custom" example on GitLab:
| https://gitlab.com/delibrium/delibrium-
| postgrest/-/tree/mast...
|
| [0] https://github.com/kiwicopple/declarative-schemas
| rotemtam wrote:
| Thanks for the mention of Atlas <3
| bob1029 wrote:
| > I am regularly surprised how bad the tooling is for
| SQL/databases
|
| Agreed. Even when using something open like SQLite, you will
| find a lot of difficulty in answering simple (to me) questions
| like "how do I parse this command text into an AST".
| j45 wrote:
| SequelPro is quite decent for MySql.
|
| Tooling for Postgres seems to be more for the technical who
| prefer command line than not.
| jonquest wrote:
| Sequel Ace is the forked and actively developed version of
| Sequel Pro. I don't think the owners of Sequel Pro ever
| announced it was abandoned, but the GitHub repo's lack of
| what appears to be any real development activity certainly
| suggests it is.
| j45 wrote:
| That's great to know, thanks, I'll try it out.
|
| At this point my muscle memory is on the Sequel Pro
| shortcut keys, except I'm finding myself around Postgres
| more and more.
| kshahkshah wrote:
| Check out Beekeeper Studio
| codeptualize wrote:
| Will try!
|
| It looks quite similar to table plus, any killer features I'm
| overlooking?
| bbkane wrote:
| Love Beekeeper Studio!
| rapind wrote:
| A monthly fee? No thanks.
| fragmede wrote:
| The stereotype of software devs being the absolute cheapest
| bastards, despite being well paid, lives on. These people
| put time and effort into building a thing, and giving them
| money for it is reprehensible?
| VincentEvans wrote:
| I'm not the people you are responding to, but I'll share
| my take as a dev who buys some tools and turns my nose at
| the others.
|
| The difference is - whether it's a purchase or a
| subscription.
|
| I'll happily buy a tool, and happily will buy upgrades
| every so often.
|
| I will absolutely resist paying for subscriptions unless
| you are delivering some sort of continuous service and I
| won't be fooled by gimmicky cloud integrations just to
| make that claim.
| thiht wrote:
| Same for me, I avoid subscriptions as much as possible.
|
| I'm ok with the model of TablePlus however: pay for a
| license, it's valid for a year, and at the end of the
| year you keep the current version available forever but
| no more updates. And you get a discount if you decide to
| renew your license
| kshahkshah wrote:
| Sheesh. It's open source, has a free version, and then a
| premium version so the bootstrapped, not-VC backed,
| creators avoid starving themselves and their families while
| working on the tool...
| rathboma wrote:
| Hi! I'm the bootstrapped, non VC backed creator of
| Beekeeper Studio. My open source version is good,
| probably too good, lol.
|
| Thanks for the mention!
| spiderice wrote:
| > probably too good, lol
|
| Lol, this is too true. I use Beekeeper Studio every day.
| Every once in a while I think to myself, "I should see if
| the full version is worth paying for yet". Then I check
| out the features and, while they look great, the free
| version has absolutely everything I need.
|
| Thanks for such a great product. I'll stop freeloading
| eventually!
| mkl wrote:
| Please make your screenshot carousel stop automatically
| rotating after it is interacted with; it's really hard to
| take in the details of the screenshots.
| rathboma wrote:
| Good idea, I'll do that, thanks!
| rapind wrote:
| The pricing looks like SaaS only. I'm happy to pay a one-
| time fee for software (even when it doesn't include
| future versions), but not a subscription, unless of
| course there is a common sense benefit to a subscription
| (like paying for additional support on top of the fixed
| price).
|
| Anyways, once taking the time to re-read the pricing
| screen subtleties it is sort of a one-time fee (billed as
| one year of subscription to gain indefinite use), so
| kudos to the developer, but I have to say it's really
| non-obvious to me at least.
|
| Also the availability of a community edition is great,
| but again non-obvious.
| gabereiser wrote:
| Sadly, this is why this space has laggard for so long.
| Devs don't want to pay for tooling but expect others to
| pay for their product.
| Xymist wrote:
| There is an important differentiator, though. I'm happy
| to pay _once_ for tooling as a product, and potentially
| for subsequent major versions. I am not, however, willing
| to be a source of MRR.
| spapas82 wrote:
| The libpg query library has a very important problem: It does not
| work on windows
| https://github.com/pganalyze/libpg_query/issues/44
|
| I'd recommend starting with fixing that instead. It would be much
| more helpful for the community.
| Operyl wrote:
| Sounds like they'd love your contribution. I hate when people
| prescribe tasks to others like this.
| kiwicopple wrote:
| yes, we (and I assume the pganalyze team) would always
| appreciate contributions
|
| fwiw, we know of this limitation and decided the acceptable
| workaround for Windows devs is simply to host the language
| server and they can connect to it via TCP.
| spapas82 wrote:
| Can't you just give some love to the issue
| https://github.com/pganalyze/libpg_query/issues/44 instead
| ? As I said before this would be very helpful for the
| community because there are a lot of libraries that use
| libpg_query and cannot be used on windows (f.e see
| https://github.com/lelit/pglast/issues/7).
|
| It seems that the only problem for fixing the problem is:
|
| > Thanks for the offer, but the problem is our team being
| time limited / having an engineer with a Windows machine
| ready to take this on, not that we wouldn't want to pay
| someone to work on it :)
|
| (https://github.com/pganalyze/libpg_query/issues/44#issueco
| mm...)
|
| Hosting the LSP elsewhere is not really needed since if
| people wanted to go that way they could use Remote ssh
| (https://code.visualstudio.com/docs/remote/ssh) to host the
| whole dev environment on linux and connect to it.
|
| Thank you
| macintux wrote:
| After 5 years of spinning wheels, maybe it's time to
| accept that Windows is a second-class citizen. That's why
| WSL exists, after all.
|
| (Speaking as someone who dreaded the "inevitable" victory
| of Windows on the desktop in the 90s I might be a little
| biased/overjoyed.)
| kiwicopple wrote:
| cool, we'll look into helping at an appropriate time.
| Since we are still developing the LSP, this issue isn't
| affecting anyone
|
| > the only problem for fixing the problem is
|
| Hopefully it's as easy as you make it sound!
| bavell wrote:
| Just use a serious development OS instead
|
| ;)
| lfittl wrote:
| We at pganalyze would definitely welcome help here - and
| if anyone would like to give this a try - feel free to
| email me, happy to talk this through, email is in my
| profile.
|
| Postgres itself supports Windows, the main challenge is
| identifying the relevant files to pull in (since we use a
| subset of the full source code), and testing the changes.
| It should be fairly quick for someone who has C
| development experience on Windows, with a working
| development environment.
| avg_dev wrote:
| Thanks, looks very interesting.
|
| I have a couple of questions:
|
| 1. Will I be able to use this in my IDE (say JetBrains or VSCode)
| alongside the programming language's LSP? So that this project
| would only be in effect for the Pg SQL bits?
|
| 2. I am a Rust newbie but I'm an experienced developer. Is there
| any room for someone like me to contribute to the project?
| kyrra wrote:
| 1) looks like intelliJ paid versions support (or will support)
| LSPs soon. https://blog.jetbrains.com/platform/2023/07/lsp-for-
| plugin-d...
|
| > Starting with the 2023.2 release cycle, the LSP API is
| publicly available as part of the IntelliJ Platform in the
| following IDEs: IntelliJ IDEA Ultimate, WebStorm, PhpStorm,
| PyCharm Professional, DataSpell, RubyMine, CLion, Aqua,
| DataGrip, GoLand, Rider
| cube2222 wrote:
| I think paid jetbrains IDEs already do this on their own, as
| they embed datagrip, no?
|
| It checks the syntax, gives you autocomplete based on the
| databases you are connected to, it even supports string
| language injection, so you'll get SQL autocomplete and checking
| for strings containing SQL in your code.
|
| I'd love to understand what the advantages here are, other than
| the obvious one of being available for many editors as a
| language server.
| michaelcampbell wrote:
| I'm not sure I'm a power user enough to notice a difference
| but I've had tremendous luck with jetbrains datagrip
| (standalone and embedded) when dealing with PG syntax. The
| highlight and formatting work a treat.
| TkTech wrote:
| Yes, the jetbrains already have all these features and more
| (such as reflecting pg functions, tables, columns, schemas,
| etc).
|
| You wouldn't really notice a difference using this, except
| your general autocompletes would get worse, and very
| complex sql might get more correct (I break datagrip's
| parser occasionally)
| kiwicopple wrote:
| 1. yes this is possible, although it depends on your IDE. Here
| is a relevant discussion for eclipse (which also links to the
| VSCode implementation):
| https://github.com/eclipse/che/issues/4609. Note: i also didn't
| know how this worked, so I learned something today too.
|
| 2. Yes, absolutely. Feel free to reach out to me directly, or
| just start contributing directly if you want
| SpaghettiCthulu wrote:
| > 1. Will I be able to use this in my IDE (say JetBrains or
| VSCode) alongside the programming language's LSP? So that this
| project would only be in effect for the Pg SQL bits?
|
| I think that would depend on IDE support. For example,
| JetBrains IDEs have a feature for this.
| yrashk wrote:
| Great project that helps creating better DX for Postgres!
|
| At Omnigres [1] we also use libpg_query for programmatic query
| manipulations as libpg_query has a deparser and that allows one
| to manipulate AST and output the text representation back.
|
| I'm trying to find time to contribute Postgres 16 support to it!
|
| [1] Omnigres: https://github.com/omnigres/omnigres
| lfittl wrote:
| Thanks Yuri - and appreciate your contributions to libpg_query!
|
| We at pganalyze have plans to add Postgres 16 support to
| libpg_query sometime between the RC1 and the final release -
| mostly to watch out for the rare case where a feature gets
| reverted during the beta releases.
|
| If you'd like to have a go at it before then definitely welcome
| (here is some context on the extraction process using libclang:
| https://pganalyze.com/blog/pg-query-2-0-postgres-query-
| parse...), and we'll also need people to test the PR once
| available.
| [deleted]
| toasted-subs wrote:
| It's surprising how powerful Postgres is and seeing tools to make
| it easier seems extremely nice!
| pama wrote:
| Looks great. Has anyone tried an integration with Emacs?
| ComputerGuru wrote:
| What kind of support do we have editor-side for swapping between
| "LSP contexts" automatically? If I'm editing a .cs file and my
| editor is using the C# LSP, then start something that a plugin
| <somehow> recognizes as entering into an SQL mode as I type
| `foo("SELECT ..` can that somehow trigger the pgsql LSP too?
|
| (I'm a vim user but I'll accept a VS Code answer since that's
| basically "state of the art" when it comes to LSP and where most
| others get their inspiration from.)
| marcelarie wrote:
| I don't know if this exists but it could be done using
| Treesitter. This is already done for syntax highlighting, nvim
| could check the syntax from a string after a specific pattern,
| like gql`` in Typescript.
|
| This should be configured by the user, idk if a default
| implementation could work correctly in all cases.
| petrzjunior wrote:
| JetBrains's IntelliJ and friends do that with language plugins.
| They detect the language according to keywords and patterns and
| are able to do highlighting and intellisense for multiple
| languages in a single file. I have not tried this with LSP
| though, because LSP support landed just in the last version.
| ComputerGuru wrote:
| Yeah, (neo)vim can do that for non-lsp with a filetype like
| html.css or similar whichbloads both syntax rules possibly
| with customizations to determine when it switches into which
| of the two modes. But again, I don't know how that works with
| lsp.
| swader999 wrote:
| Neovim does this. For example, if you have two lsp configured
| in nvm-lspconfig.lua as follows, it will use a specific lsp
| tailored to either SQL or ruby:
|
| -- Initialization of Neovim's LSP client local nvim_lsp =
| require('lspconfig')
|
| -- Setup for the Ruby LSP nvim_lsp.solargraph.setup {}
|
| -- Setup for an SQL LSP (assuming one exists with the name
| 'sql_lsp' in this example) nvim_lsp.sql_lsp.setup {}
| NilsIRL wrote:
| I think what parent comment is asking for is the ability
| switch between languages withing a single file. I don't think
| this will work with the setup you described.
| swader999 wrote:
| No, it would not.
| imams666 wrote:
| [flagged]
| tacone wrote:
| Very nice. Hope to see something along the lines of Prettier for
| SQL, one day. That's sorely needed.
| freedomben wrote:
| I've been looking for something like this recently, and there
| are actually quite a few options. Unfortunately, they can only
| handle files up to a particular size. My use case is to pretty
| up a huge SQL dump so that I can grab it. Every existing tool
| tries to read the entire thing into memory, and ends up
| crashing.
| steinroe wrote:
| the language server protocol supports range operations,
| although I don't know how many editors enable it. plus it's
| arguably harder to implement. I will add benchmarks once the
| server is ready, and we can see how far we can get from
| there. thanks for the feedback!
| steinroe wrote:
| it's on the roadmap! once the parser is stable and an advanced
| and scalable data model is implemented, features like this will
| hopefully be quite straightforward to implement.
| Exuma wrote:
| Man I was just looking for this forever, you rock.
___________________________________________________________________
(page generated 2023-08-06 23:00 UTC)