Deprecating builtins with unmaintained upstream or native LSP replacement #58

mochaaP · 2024-01-11T18:20:24Z

Related projects:

I'm thinking of cleaning up some builtins with the following criteria:

Unmaintained (> 1y) or deprecated by upstream with better and widely adopted replacement available (e.g. JSHint, Luacheck)
Fully overlapped feature (markdownlint, markdownlint-cli2, mdl)
Native LSP available (e.g. ESLint, Biome, Taplo, tsc)

Planned to remove (will keep updating):
edit history → #58 (comment)

	deleted:    code_actions/eslint.lua        (use eslint-language-server / available in none-ls-extras.nvim)
	deleted:    code_actions/eslint_d.lua      (use eslint-language-server / available in none-ls-extras.nvim)
	deleted:    code_actions/ltrs.lua          (use ltex-ls)
	deleted:    code_actions/shellcheck.lua    (use bashls / available in gbprod/none-ls-shellcheck.nvim)
	deleted:    code_actions/xo.lua            (use eslint-language-server)
	deleted:    diagnostics/bandit.lua         (use ruff)
	deleted:    diagnostics/chktex.lua         (use texlab)
	deleted:    diagnostics/clang_check.lua    (use clangd)
	deleted:    diagnostics/cpplint.lua        (use clangd / available in none-ls-extras.nvim)
	deleted:    diagnostics/curlylint.lua
	deleted:    diagnostics/deno_lint.lua      (use deno lsp)
	deleted:    diagnostics/eslint.lua         (use eslint-language-server)
	deleted:    diagnostics/eslint_d.lua       (use eslint-language-server)
	deleted:    diagnostics/flake8.lua         (use ruff / available in none-ls-extras.nvim)
	deleted:    diagnostics/gospel.lua
	deleted:    diagnostics/jshint.lua         (use eslint-language-server)
	deleted:    diagnostics/jsonlint.lua       (use jsonls)
	deleted:    diagnostics/luacheck.lua       (use selene / available in gbprod/none-ls-luacheck.nvim)
	deleted:    diagnostics/misspell.lua
	deleted:    diagnostics/php.lua            (available in gbprod/none-ls-php.nvim)
	deleted:    diagnostics/protoc_gen_lint.lua (use buf)
	deleted:    diagnostics/puglint.lua
	deleted:    diagnostics/psalm.lua          (use psalm lsp / available in gbprod/none-ls-psalm.nvim)
	deleted:    diagnostics/puppet_lint.lua
	deleted:    diagnostics/pycodestyle.lua    (use ruff)
	deleted:    diagnostics/pydocstyle.lua     (use ruff)
	deleted:    diagnostics/pylama.lua         (use ruff)
	deleted:    diagnostics/pyproject_flake8.lua (use ruff)
	deleted:    diagnostics/ruff.lua           (use ruff lsp)
	deleted:    diagnostics/semistandardjs.lua (use eslint-language-server)
	deleted:    diagnostics/shellcheck.lua     (use bashls / available in gbprod/none-ls-shellcheck.nvim)
	deleted:    diagnostics/standardjs.lua     (use eslint-language-server)
	deleted:    diagnostics/standardrb.lua     (use standardrb lsp)
	deleted:    diagnostics/tsc.lua            (use tsserver)
	deleted:    diagnostics/typos.lua          (use typos-lsp)
	deleted:    diagnostics/vulture.lua        (use ruff)
	deleted:    diagnostics/xo.lua             (use eslint-language-server)
	deleted:    formatting/autoflake.lua       (use ruff)
	deleted:    formatting/autopep8.lua        (use ruff)
	deleted:    formatting/beautysh.lua        (use shfmt)
	deleted:    formatting/brittany.lua        (use haskell-language-server)
	deleted:    formatting/cabal_fmt.lua       (use haskell-language-server)
	deleted:    formatting/deno_fmt.lua        (use deno lsp)
	deleted:    formatting/docformatter.lua    (use ruff)
	deleted:    formatting/dprint.lua          (use dprint lsp)
	deleted:    formatting/dtsfmt.lua          (upstream is missing)
	deleted:    formatting/eslint.lua          (use eslint-language-server)
	deleted:    formatting/eslint_d.lua        (use eslint-language-server)
	deleted:    formatting/fixjson.lua         (use jsonls)
	deleted:    formatting/fourmolu.lua        (use haskell-language-server)
	deleted:    formatting/htmlbeautifier.lua  (use tidy)
	deleted:    formatting/jq.lua              (use jsonls)
	deleted:    formatting/json_tool.lua       (use jsonls)
	deleted:    formatting/jsonnetfmt.lua      (use jsonnet-language-server)
	deleted:    formatting/latexindent.lua     (use texlab / available in none-ls-extras.nvim)
	deleted:    formatting/lua_format.lua      (use stylua)
	deleted:    formatting/markdown_toc.lua    (use marksman)
	deleted:    formatting/perlimports.lua     (use PerlNavigator)
	deleted:    formatting/perltidy.lua        (use PerlNavigator)
	deleted:    formatting/puppet_lint.lua
	deleted:    formatting/pyflyby.lua         (use ruff)
	deleted:    formatting/reorder_python_imports.lua (use ruff, isort or usort)
	deleted:    formatting/ruff.lua            (use ruff lsp)
	deleted:    formatting/ruff_format.lua     (use ruff lsp)
	deleted:    formatting/rustfmt.lua         (use rust-analyzer)
	deleted:    formatting/semistandardjs.lua  (use eslint-language-server)
	deleted:    formatting/standardjs.lua      (use eslint-language-server)
	deleted:    formatting/standardrb.lua      (use standardrb lsp)
	deleted:    formatting/standardts.lua      (use eslint-language-server)
	deleted:    formatting/stylish_haskell.lua (use haskell-language-server)
	deleted:    formatting/taplo.lua           (use taplo lsp)
	deleted:    formatting/templ.lua           (use templ lsp)
	deleted:    formatting/terrafmt.lua
	deleted:    formatting/trim_newlines.lua   (use editorconfig)
	deleted:    formatting/trim_whitespace.lua (use editorconfig)
	deleted:    formatting/vfmt.lua            (use vls)
	deleted:    formatting/xmlformat.lua       (use lemminx)
	deleted:    formatting/xmllint.lua         (use lemminx)
	deleted:    formatting/xq.lua              (use lemminx)
	deleted:    formatting/yq.lua              (use yamlls)
	deleted:    formatting/zigfmt.lua          (use zls)

The text was updated successfully, but these errors were encountered:

jakenvac · 2024-01-11T20:35:54Z

I support this. Maybe create a 'legacy' branch so people can easily use an old version of the plugin if they rely on something that is due to be removed?

mochaaP · 2024-01-11T20:46:07Z

This won't happen very soon without further notice. I guess we could add a notice on startup if users are using any of the deprecated builtins, and finally remove them, for likely 1 to 2 months later?

Also, users could just copy & paste the builtins they use into their config, so I don't feel the very need to maintain a separate branch.

mochaaP · 2024-01-12T08:19:16Z

Hi @towry @tiagovla could you give some feedback and reasons on the previous -1? It will really help the decision 😄

kmoschcau · 2024-01-15T10:43:11Z

Hi, for the unmaintained ones, what is the main motivation to remove them? Is it just out of caution, that they might break? I have contributed two diagnostics parsers (checkstyle and pmd), which I have last touched over two years ago, but they should still work. Outright removing them might not be the best idea.

mochaaP · 2024-01-15T12:47:34Z

@kmoschcau

for the unmaintained ones

It's just for the upstream abandoned projects. pmd and checkstyle are all fine, since upstream actively maintains them :)

kmoschcau · 2024-01-15T14:10:37Z

Ah OK gotcha. I first understood that whether or not the builtins themselves are maintained or not is the deciding factor. I simply misread. In that case this sounds like a sensible idea. Carry on. 😀

mochaaP · 2024-01-21T20:46:00Z

(moved to the issue body)

wookayin · 2024-01-21T21:17:01Z

Please don't remove yapf, pyink, flake8, black, isort, pep8, etc (anything related to python/ruff). These are all still popular and widely used --- IMHO Ruff is still not mature enough to replace all the formatters.

I also find that the list you suggest is quite aggressive. Not only for python but for other langs. The removal/deprecation should be done in more like a opt-in manner rather than opt-out manner.

Also I think it'd be great to main the current, up-to-date list of the plan in the body (i.e. at the very top) of this issue because comments in the middle will get easily out of attention?

mochaaP · 2024-01-21T21:25:36Z

@wookayin:

Please don't remove yapf, pyink, flake8, black, isort, pep8, etc (anything related to python/ruff). These are all still popular and widely used --- IMHO Ruff is still not mature enough to replace all the formatters.

See the FAQ here. I tried not to break things if there are a significant number of rules not implemented.

I also find that the list you suggest is quite aggressive. Not only for python for other langs. The removal/deprecation should be done in more like a opt-in manner rather than opt-out manner.

The change may start rolling out on a separate branch first. I look forward to merging that into master in 1–2 years.
The removals are mostly due to the overhead on executing binaries, especially on Windows with EDR activated that hooks into LaunchProcess. Furthermore, most recommendations are using the same underlying engine.

Also I think it'd be great to main the current, up-to-date list of the plan in the body (i.e. at the very top) of this issue because comments in the middle will get easily out of attention?

I will put a link to this comment (to preserve edit history).

wookayin · 2024-01-21T21:34:20Z

See the FAQ here. I tried not to break things if there are a significant number of rules not implemented.

That's ruff's goal, but at this point not really. Ruff is a good diagnostics tool so for diagnostics maybe yes, but as a formatter I don't think it's mature enough yet. Your list includes more than what Ruff is currently capable of. For flake8 I would say it's OK (although very controversial) to remove, but ruff is never going to be the 100% exactly the same with other formatters that are still widely used in many projects, it can't be a replacement. For instance: isort, black, yapf, etc. which are all clear NO. Ruff-formatter aims to be as similar as black, although it isn't ATM, and black is not the only formatter in the Python community.

https://docs.astral.sh/ruff/faq/#how-does-ruffs-import-sorting-compare-to-isort.
https://docs.astral.sh/ruff/faq/#is-the-ruff-linter-compatible-with-black

mochaaP · 2024-01-21T21:44:16Z

Fair point, thanks. I've restored isort, black, yapf, pyink from the list.

sblask · 2024-01-21T22:25:55Z

I never used flake8 and have not looked into ruff, but removing a tool because there is an alternative tool can be problematic. You don't always have the choice of what tool to use. So if ruff doesn't do exactly the same thing and uses the same configuration files it's not a good replacement. Same might be the case for other tools.

wookayin · 2024-01-21T22:49:24Z

@mochaaP Thanks for considering the suggetsion!

but removing a tool because there is an alternative tool can be problematic.

+1, I second this point by @sblask. None-ls.nvim should be deprecating things only if the project is abandoned (or more precisely, users are also leaving and abandoning it) and good modern alternatives are available. There could be inactive, not-so-quite-updated tools that can still work great and be used in many projects. None-ls.nvim is a collection of tools that users can pick and start using out-of-box. If a tool that's already available in our curated list is abandoned, it's provided as-is, hence no maintenance cost added.

mochaaP · 2024-01-22T02:57:50Z

Since this project is a community effort, the most important factor to take into consideration is your feedback. Thank you all for caring about this project! ♥️

g-plane · 2024-01-23T06:27:46Z

dprint also has its native language server: dprint/dprint#803

mochaaP · 2024-01-23T17:20:10Z

@g-plane: updated, thanks.

pysan3 · 2024-01-23T18:52:07Z

Hi, do you plan to remove the tools listed above also from mason.nvim and mason-tool-installer?
@williamboman @WhoIsSethDaniel

Or only for the recipes defined in none-ls?

WhoIsSethDaniel · 2024-01-23T19:45:03Z

Hi, do you plan to remove the tools listed above also from mason.nvim and mason-tool-installer? @williamboman @WhoIsSethDaniel

Or only for the recipes defined in none-ls?

There's no change to mason-tool-installer. It will continue to support whatever mason can download.

g-plane · 2024-01-28T07:21:15Z

rustfmt shouldn't be deprecated. rust-analyzer won't do anything about formatting, and the rust-analyzer config in lspconfig has nothing about rustfmt or formatting.

mochaaP · 2024-01-28T08:37:41Z

👌

gbprod · 2024-01-30T08:33:29Z

Hi!
I think it's a good thing to remove obsolete/unmaintained tools or tools with better alternative (LSP) !

Anyway, I still using the php builtin (mainly because I sometimes don't want to use a LSP server and because it's faster) and I've tried to create a none-ls plugin here : https://github.com/gbprod/none-ls-php.nvim. I think it could be a good alternative for some tools that none-ls's core team does'nt want to maintain, maybe it could be documented or liked somewhere ?
I'll probably do the same with luacheck that I'm still using.

Thanks for your work !

mochaaP · 2024-01-30T09:54:26Z

Hi @gbprod,
Your project was already featured here! ;)

mochaaP · 2024-01-31T08:08:57Z

@altermo:
https://github.com/neovim/nvim-lspconfig/tree/master/lua/lspconfig/server_configurations/typos_lsp.lua typos-lsp is available from nvim-lspconfig ;)

Nargonath · 2024-02-01T08:06:06Z

rustfmt shouldn't be deprecated. rust-analyzer won't do anything about formatting, and the rust-analyzer config in lspconfig has nothing about rustfmt or formatting.

You can definitely install rustfmt through rustup but how do you link the rustup install with none-ls? For now I still install rustfmt through mason-null-ls.

mochaaP · 2024-02-01T08:36:01Z

@g-plane (#58 (comment)):

https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/caps.rs#L71
https://github.com/rust-lang/rust-analyzer/blob/master/crates/rust-analyzer/src/handlers/request.rs#L1915
I suppose rustfmt is actually included in rust-analyzer? Correct me if I'm wrong.

GR3YH4TT3R93 · 2024-02-25T07:14:23Z

I'm still extremely new to nvim, how would I tie that in with mason/ mason-null-ls or am I S.O.L. until they're integrated?

mochaaP · 2024-02-25T07:17:47Z

You can manually add eslint_d to mason.nvim's ensure_installed.

GR3YH4TT3R93 · 2024-02-25T07:29:51Z

No, you can't. If called in mason.setup it does nothing. In mason-lspconfig, it throws an error that it's not a valid entry. How do I fix this?

GR3YH4TT3R93 · 2024-02-25T07:53:28Z

This is an absolutely horrible discision.

This breaks countless ppl's configs and new devs are left with no way to fix their configs other than with extremely vague and unhelpful comments from the person actually making the changes.

This needs to be rolled back ASAP.

GR3YH4TT3R93 · 2024-02-25T08:11:12Z

Like seriously, I tell you I'm extremely new to neovim and then you give literally at most 8 word sentences to tell me how to "fix" the problem YOU created. Wtf is wrong with you? We shouldn't have to fix what you broke in the first place. Just simply DO NOT depreciate tools people are actively using and are under active development/ mantainership.

GR3YH4TT3R93 · 2024-02-25T08:16:40Z

Put another way, if you're unwilling to actually give meaningful help to the breaking changes you're making, you should NOT be making them.

mochaaP · 2024-02-25T08:24:38Z

Feel free to continue shouting, but this won't help solve any problems.

This issue is pinned for >2mo, has been on Reddit for >1mo and as a last resort, a notice on startup with a grace period for at least a week. Yet you ignored all these messages and refused to migrate nor pin to an old commit.

If you really cared about this you should have noticed it from the first place. But the reality is you neither care about those projects you use nor anyone maintaining them. You're just straight up hurting people doing all the work of their free will.

Please, at least be nice to each other.

GR3YH4TT3R93 · 2024-02-25T08:47:17Z

Like I've said three times now, I'm extremely new to neovim that by definition means I am not up-to-date on all the goings-ons of every plugin I'm using.

"If you really cared about being able to use linting in your projects, you should've noticed that one supporting plugin is going to break eslint for you" yeah, no. That's not realistic at all. Most people don't go to all the different repos for the plugins they use to make sure there's no breaking changes. They just update their plugins and be done with it.

"refused to migrate" what do you think my second question was? Literally how do I migrate to use the new extras package with mason. To which you replied with yet another vague and unhelpful answer.

"if you really cared blah blah blah you're just straight up hurting people doing all the work of their free will"

Nobody asked you to do this. You took it upon yourself to break people's configs because you and a vocal minority decided it was "better" instead of just leaving it alone and if it breaks, leaving it up to people to step up and fix it or fixing it yourself if/when it breaks.

and if YOU really cared about the project or people maintaining it, you'd be quick to assist new people with ways to migrate or fix the issue like I tried to do so that others can come to this thread and read how to solve the issue but instead we've got this wall of crap and still no solution to integrate the extras package with mason or get eslint_d to stop causing the stupid warning to appear.

fgsch · 2024-02-25T10:11:34Z

This is a long issue, so apologies in advance if this was mentioned earlier. That said, you added the deprecation notice yesterday and you're retiring the builtin in March, which is next week? I'd expect a bit more time for people to migrate.

mochaaP · 2024-02-25T10:43:11Z

@fgsch:

you added the deprecation notice yesterday and you're retiring the builtin in March, which is next week? I'd expect a bit more time for people to migrate.

The migration should be an easy fix, but if people find it needs more time to migrate, we could delay the merge. 🙂

jmsdrh · 2024-02-25T11:01:23Z

I'm using beautysh for formatting, but it's marked for removal.bashls and shfmt have been suggested as replacements, but neither of those seem to support zsh, which is what I use (it's the default on macOS). Are there any other formatters that supports zsh?

You can set filetypes for both

local nl = require("null-ls")
nl.builtins.formatting.shfmt.with({
	filetypes = { "sh", "zsh" },
})

require("lspconfig").bashls.setup({
	filetypes = { "sh",  "zsh" },
        ...
        ...
})

mochaaP · 2024-02-25T11:05:26Z

That does not work, since shfmt does not understand zsh-specific syntax and will throw an error.

keith-rollin · 2024-02-25T11:05:37Z

I'm using beautysh for formatting, but it's marked for removal.bashls and shfmt have been suggested as replacements, but neither of those seem to support zsh, which is what I use (it's the default on macOS). Are there any other formatters that supports zsh?

You can set filetypes for both

Thanks! I'll have to try those out. I hope those tools will actually handle zsh. Some of the Issues for them talk about adding support, but it didn't seem to happen.

sblask · 2024-02-25T11:06:49Z

I don't know about other people's workflows, but I don't update my plugins unless I have to (because one is causing a problem for example) or setup a new machine. Otherwise I'd be busy with fixing something all the time. So unless you expect people to update their plugins daily, one week deprecation will not be enough. How about one year?

But I don't understand what the issue is actually. If a tool has been abandoned it will hardly cause problems because the output format will not change. If a tool does cause problems, why not wait until someone fixes it and if that doesn't happen it can still be removed if there is an alternative? I am watching all activity on this repository and so far there have been no problems with any existing tools. It feels like removing support for tools is totally unnecessary. What problem does it solve? What future work does it enable that can't be done at the moment? Just doing something for the sake of it and causing trouble for other people by doing so would be terrible.

kmoschcau · 2024-02-25T11:59:43Z

In general the problem is that this plugin only provides functionality to integrate external tools with neovim's LSP client. The plugin has no control over when those external tools do introduce breaking changes. Builtins being deprecated here means that nobody is looking at those external tools in question and fixing them when they break. Builtins that are still in none-ls somewhat carry with them an expectation that they will be fixed when the external tool introduces breaking changes.
Deprecating some tools where there's an adequate replacement reduces the work necessary for none-ls maintainers. Further some tools barely have any users and thus contributors. For example I only added checkstyle and pmd support because I needed it at the time. I have not been writing any Java for a while now so there was no reason for me to check whether these still work with current versions of those tools.

I do agree though that a longer deprecation period would be better. Keep the builtins around a little longer, but make it clear there is no priority to fix them, if they break. For that matter it might also be a good idea to add some alternative way of telling the user instead of notifications. A health check for example or using :NullLsInfo.

Lastly, if anyone is using plugins without pinning a version, they are opting into breaking changes. It's as simple as that. Most plugins I know do use some form of semantic versioning even, so you wouldn't even be stuck with just one exact commit. I personally do not pin plugin versions, but I do use Lazy as a plugin manager and do actually look at the changes for each update to determine whether I need to fix something. That is up to everyone's personal preference. Long story short, the tools are there for people to not have to deal with breaking changes that often, please use them. That also means don't come complaining about breaking changes when you did not pin a version.

catgoose · 2024-02-25T13:05:23Z

The problem with this decision is people don't mind using deprecated or unmaintained projects. Instead of removing them, simply mark in the appropriate markdown readme files that the source is deprecated. At this point, why not just use https://github.com/mhartington/formatter.nvim

SuyashPatil-29 · 2024-02-25T13:07:25Z

[null-ls] You required a deprecated builtin (diagnostics/eslint.lua), which will be removed in March.
Please migrate to alternatives: #58

Any info on how to solve this would be appreciated

mochaaP · 2024-02-25T13:11:23Z

@SuyashPatil-29 Please search eslint in the thread 😃, you can either use the native LSP (https://github.com/neovim/nvim-lspconfig/blob/master/doc/server_configurations.md#eslint) or use none-ls-extras.nvim (https://github.com/nvimtools/none-ls-extras.nvim/blob/main/lua/none-ls/diagnostics/eslint.lua).

mochaaP · 2024-02-25T13:16:19Z

@catgoose:

The problem with this decision is people don't mind using deprecated or unmaintained projects.

I mind the quality of this project.

At this point, why not just use mhartington/formatter.nvim

You are welcome to use alternatives! Neovim is designed to be pluggable, so if you are unsatisfied with this project, you are free to use other tools that fit your needs best. Please don't have hard feelings :)

rorj · 2024-02-25T13:24:21Z

So is installing none-ls-extras and adding eslint_d to mason's ensure_installed is enough to continue using it? I'm still getting deprecation messages.

GR3YH4TT3R93 · 2024-02-25T13:26:02Z

or just tell this idiot to sod off and stop being a maintainer if they're just going to cause problems for everyone.

sblask · 2024-02-25T13:28:10Z

@kmoschcau Why not cross the bridge when you get there? With the current approach you proactively break tools because they MIGHT break in the future. If nobody is working on a tool, how can they introduce a breaking change? The only way an existing integration of an abandoned tool breaks is because of changes in none-ls.

If it's just about the expectation, that can be solved with one sentence in the README: Existing built-ins represent a snapshot in time and might not work with current versions of a tool - patches welcome!

Who is to decide what an adequate replacement is if you work on a project where it's not your choice to change the tooling?

If you think everybody should pin their plugins, why even bother with a deprecation period? And pinning doesn't work if I need a fix or new tool. If the solution to that is to update and then copy removed builtins into my config, why even provide a plugin?

@mochaaP tools being deprecated or unmaintained has nothing to do with the quality of this project. I see the builtins as a thing apart to allow users to get started easily. It might as well be a completely separate project, but it's just easier if it's bundled. none-ls-extras is just arbitrary

GR3YH4TT3R93 · 2024-02-25T13:30:43Z

@sblask thank you for saying what I as an autist am finding impossible atm. I appreciate it.

mochaaP · 2024-02-25T13:32:34Z

@GR3YH4TT3R93 I've created a PR in your config repository to fix the eslint_d issue. Why do you have to be so mad and rude?

as an autist

I hope you are really so. I have been diagnosed with ASD for so long, yet I found all your behavior so intruding and hurtful.

kmoschcau · 2024-02-25T13:41:41Z

@sblask please read again what I wrote. I do agree with you that they should just stay in, but marked as deprecated. That should already set the appropriate expectations. I also agree that this notification might not have been the best way to communicate all of this.

With the current approach you proactively break tools because they MIGHT break in the future.

As said above, I agree with that.

If nobody is working on a tool, how can they introduce a breaking change? The only way an existing integration of an abandoned tool breaks is because of changes in none-ls.

This is wrong, because of a misunderstanding. What I meant is builtins where only the integration is abandoned, but the upstream, external tool is still maintained. There upstream changes might break things while nothing in none-ls changed. These cases should not be deprecated by this list and also are not covered by the criteria in the first post. I just wanted to say I would fully understand why those might be marked as deprecated as well.

@mochaaP I agree with you that somehow wanting to get rid of code is a good thing. However I would suggest we maybe find a different approach. At the very least, migration instructions should be added somewhere. Edit: With that I mean more complete migration instructions. Not everyone is as familiar with neovim's API as you and I seem to be.

…upport in none-ls.

mochaaP self-assigned this Jan 11, 2024

mochaaP pinned this issue Jan 11, 2024

This comment was marked as off-topic.

Sign in to view

mochaaP mentioned this issue Jan 23, 2024

feat(builtins): add vfmt as a formatting builtin #64

Merged

This comment was marked as resolved.

Sign in to view

This comment has been minimized.

Sign in to view

nvimtools locked and limited conversation to collaborators Feb 25, 2024

mochaaP converted this issue into discussion #81 Feb 25, 2024

nshen referenced this issue in nshen/InsisVim Feb 28, 2024

feat: replace eslint_d with eslint language server

f8b7e87

nshen referenced this issue in nshen/InsisVim Mar 6, 2024

feat: use jsonls to format JSON files due to the removal of fixjson s…

228ca87

…upport in none-ls.

This issue was moved to a discussion.

Deprecating builtins with unmaintained upstream or native LSP replacement #58

Deprecating builtins with unmaintained upstream or native LSP replacement #58

Comments

mochaaP commented Jan 11, 2024 • edited

Related projects:

jakenvac commented Jan 11, 2024

mochaaP commented Jan 11, 2024

mochaaP commented Jan 12, 2024

This comment was marked as off-topic.

kmoschcau commented Jan 15, 2024

mochaaP commented Jan 15, 2024

kmoschcau commented Jan 15, 2024

mochaaP commented Jan 21, 2024 • edited

wookayin commented Jan 21, 2024 • edited

mochaaP commented Jan 21, 2024 • edited

wookayin commented Jan 21, 2024 • edited

mochaaP commented Jan 21, 2024 • edited

sblask commented Jan 21, 2024

wookayin commented Jan 21, 2024 • edited

mochaaP commented Jan 22, 2024

g-plane commented Jan 23, 2024

mochaaP commented Jan 23, 2024 • edited

pysan3 commented Jan 23, 2024

WhoIsSethDaniel commented Jan 23, 2024

g-plane commented Jan 28, 2024

mochaaP commented Jan 28, 2024

gbprod commented Jan 30, 2024

mochaaP commented Jan 30, 2024

This comment was marked as resolved.

mochaaP commented Jan 31, 2024

Nargonath commented Feb 1, 2024 • edited

mochaaP commented Feb 1, 2024 • edited

GR3YH4TT3R93 commented Feb 25, 2024

mochaaP commented Feb 25, 2024

GR3YH4TT3R93 commented Feb 25, 2024

GR3YH4TT3R93 commented Feb 25, 2024

This comment has been minimized.

GR3YH4TT3R93 commented Feb 25, 2024 • edited

GR3YH4TT3R93 commented Feb 25, 2024

mochaaP commented Feb 25, 2024 • edited

GR3YH4TT3R93 commented Feb 25, 2024

fgsch commented Feb 25, 2024

mochaaP commented Feb 25, 2024

jmsdrh commented Feb 25, 2024

mochaaP commented Feb 25, 2024

keith-rollin commented Feb 25, 2024

sblask commented Feb 25, 2024

kmoschcau commented Feb 25, 2024

catgoose commented Feb 25, 2024

SuyashPatil-29 commented Feb 25, 2024

mochaaP commented Feb 25, 2024

mochaaP commented Feb 25, 2024

rorj commented Feb 25, 2024

GR3YH4TT3R93 commented Feb 25, 2024

sblask commented Feb 25, 2024

GR3YH4TT3R93 commented Feb 25, 2024

mochaaP commented Feb 25, 2024 • edited

kmoschcau commented Feb 25, 2024 • edited

This issue was moved to a discussion.

mochaaP commented Jan 11, 2024 •

edited

mochaaP commented Jan 21, 2024 •

edited

wookayin commented Jan 21, 2024 •

edited

mochaaP commented Jan 21, 2024 •

edited

wookayin commented Jan 21, 2024 •

edited

mochaaP commented Jan 21, 2024 •

edited

wookayin commented Jan 21, 2024 •

edited

mochaaP commented Jan 23, 2024 •

edited

Nargonath commented Feb 1, 2024 •

edited

mochaaP commented Feb 1, 2024 •

edited

GR3YH4TT3R93 commented Feb 25, 2024 •

edited

mochaaP commented Feb 25, 2024 •

edited

mochaaP commented Feb 25, 2024 •

edited

kmoschcau commented Feb 25, 2024 •

edited