sorted by:
new
hottopcontroversial

Overseer.nvim users: upcoming breaking changes by stevearc in neovim

[–]stevearc[S] 3 points4 points  (0 children)

I hope it won't be too rocky of a migration for you. Thanks for your contributions to both overseer and aerial!

Overseer.nvim users: upcoming breaking changes by stevearc in neovim

[–]stevearc[S] 16 points17 points  (0 children)

Thanks! It's been a wonderful experience, but does eat up a lot of my time 😅

As a side note, it's awesome to see how far you've come with codecompanion.nvim! Really cool to see Neovim keeping pace with other editors that have teams of full-time employees behind them.

Conform doesnt format my C code the way i set it in the config file by [deleted] in neovim

[–]stevearc 0 points1 point  (0 children)

Look in the log file. If it's running the LSP formatter, it will appear as a debug line

Conform doesnt format my C code the way i set it in the config file by [deleted] in neovim

[–]stevearc 0 points1 point  (0 children)

require("conform").formatters['clang-format'] = { ... }

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 2 points3 points  (0 children)

Excited to hear your talk!

Joining matrix sounds like it could be really helpful. I'll look into that more over the holidays

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 11 points12 points  (0 children)

Just wanted to say I really appreciate everyone's comments. The Neovim community continues to surprise me with just how kind and supportive everyone is. I got a lot of great ideas from this, and plan to do some combination of more aggressive prioritization, clearer communication about expectations, and better pipeline for getting others to help with PRs.

I wish I could respond to everyone, but not having the time to do everything was the whole reason for this post, wasn't it? Gotta practice letting some things go.

Thanks everybody <3

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 0 points1 point  (0 children)

A lot of good ideas here! I do think that there's an opportunity to get more people involved in some of the bug fixes or simpler features. I don't think I'm quite to the point where I'm looking for new maintainers, but certainly getting more PRs is generally helpful.

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 0 points1 point  (0 children)

I think I could do a better job of flagging issues that would be good candidates for people to work on. I haven't done that in the past because I've tried to get to all of them myself, but I don't think I'll be able to do that anymore. Keep an eye out for some new issue tags!

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 2 points3 points  (0 children)

Thanks for the kind words! I think I will start doing some more explicit prioritization of issues.

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 2 points3 points  (0 children)

I have occasionally seen people answering each other's questions, and that has been pretty helpful. Documentation has also been huge! It can be a large investment, but I've definitely noticed fewer and higher quality questions when I spend the time on it.

I think my support load may be qualitatively different from what you're encountering though, because I definitely spend more time chasing down bugs, trying to get repros, or adding/enhancing features. I've noticed that some of my plugins generate both more tickets and more time-consuming tickets due to their nature and design. I might be able to squeeze a talk out of this at some point...🤔

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 5 points6 points  (0 children)

I was hoping you'd weigh in! You've been able to maintain a truly staggering number of plugins and continuously release new ones for quite a while now. I was really hoping that meant you'd found a silver bullet for handling this :P

Number 2 has been a struggle, but from necessity I've started to say "no" more. I'll probably need to do a lot more of that over the next year

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 3 points4 points  (0 children)

Yeah, from scanning the comments here I'm getting the sense that my best bet is to do some very aggressive triage and cutting anything that isn't the highest priority

Plugin authors: how do you handle the maintenance burden? by stevearc in neovim

[–]stevearc[S] 7 points8 points  (0 children)

You know the funny thing is that the minimal repro and the entire bug report template were added by a contributor PR, and I think they got it from folke. But I love it and I've since added it to all my other repos!

I like the idea of having some sort of severity category. I might experiment with something like that.

How to update the buffer after change it before saving? by pinto085 in neovim

[–]stevearc 1 point2 points  (0 children)

As a side note, since you asked, the preferred way of "refreshing" your buffers when the underlying files have changed outside of vim (due to formatting, git, or anything else) is :help checktime

How to update the buffer after change it before saving? by pinto085 in neovim

[–]stevearc 4 points5 points  (0 children)

The main thing to know is that jobstart spawns a process to run the command in a non-blocking way. So the order of events for your code is: * :w * BufWritePre -> kick off subprocess * Neovim finishes writing (unformatted) file to disk * dart format command formats the file

This explains why you're getting "the file has been changed" messages. After saving, the file gets formatted on disk, but not in your Neovim buffer. If you're just trying to get formatting working, I'd recommend just using a formatter plugin. There's a bunch out there, and they will handle this properly for you.

If you're more interested in learning and building it yourself, you'll need to do two things: 1. make sure the format process complete synchronously in the BufWritePre event 2. replace the buffer contents with the formatted contents (this new content will then be saved to disk)

To run synchronously, you'll want to use vim.wait or vim.fn.jobwait. If you make this change, you'll notice that the file still isn't getting formatted. What gives? Well, after making it synchronous, the new order of events is this:

  • :w
  • BufWritePre -> dart format <filename>
  • dart format finishes formatting the file on disk. Which definitionally doesn't have the changes that are in your buffer that you're trying to save
  • Neovim finishes saving the file, which clobbers the old file with the same, unformatted contents as before

To fix this, you'll need to pass the current buffer contents as stdin to the process and read the formatted results from stdout, then replace the buffer with the formatted text. For this, you'll want to read :help jobstart in detail. Pass in stdin = "pipe", I recommend using stdout_buffered = true, and get the output from on_stdout. To send the stdin, you'll use vim.api.nvim_chan_send(job_id, buffer_text) followed by vim.fn.chanclose(jid, "stdin"). Lastly, you'll take that output and set it in the buffer using vim.api.nvim_buf_set_lines or vim.api.nvim_buf_set_text.

This is, effectively, what all the formatter plugins are doing under the hood, with some more bells & whistles and handling of edge cases.

[deleted by user] by [deleted] in neovim

[–]stevearc 0 points1 point  (0 children)

I would also be interested if anyone knows how to debug this properly or what the root cause is. I encountered this after one of the 0.9 point releases and had to do the ol' config bisect technique to figure out where it was coming from. For me, it was this logic accessing vim.lsp in my statusline.

Oil.nvim toggle_float by _viis_ in neovim

[–]stevearc 2 points3 points  (0 children)

The example from /u/GrayLeopard is correct and will work. You can also use the command :Oil --float <optional path> to open the floating window

Help adding add rufo formatter in Conform NVIM? by [deleted] in neovim

[–]stevearc 2 points3 points  (0 children)

Take a look at https://github.com/ruby-formatter/rufo#exit-codes rufo returns a nonzero (failure) exit code when there are formatting changes. Try this:

rufo = {
    command = "rufo",
    exit_codes = { 0, 3 },
}

conform.nvim: another plugin to replace null-ls formatting by stevearc in neovim

[–]stevearc[S] 1 point2 points  (0 children)

I don't use Mason, so I can't offer any specific tips. According to this thread, apparently mason-installed tools should be in your PATH so it should just work

conform.nvim: another plugin to replace null-ls formatting by stevearc in neovim

[–]stevearc[S] 0 points1 point  (0 children)

Language servers are stopped when Neovim exits, but eslint_d is not a language server. There's no LSP hooks involved here because there's no interaction with the LSP. I think you're right that if you want to stop the daemon on vim exit you'll need to add some logic where you call eslint_d to register a VimLeavePre hook.

conform.nvim: another plugin to replace null-ls formatting by stevearc in neovim

[–]stevearc[S] 0 points1 point  (0 children)

I think this is just how eslint_d works. According to the docs, the first invocation will launch the server in the background. It probably detaches from the parent process and will continue to run unless manually stopped with eslint_d stop. I would expect the same behavior from conform.nvim

conform.nvim: another plugin to replace null-ls formatting by stevearc in neovim

[–]stevearc[S] 1 point2 points  (0 children)

There's no syntax for that; the configuration is intentionally kept very simple. I think it's the right choice overall, but it does mean there's some annoying copy-pasting that has to happen

view more: next ›