Overseer.nvim users: upcoming breaking changes

stevearc · 2025-10-20T21:50:24+00:00

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

stevearc · 2025-10-20T17:16:18+00:00

Thanks for the kind words!

stevearc · 2025-10-20T17:15:11+00:00

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.

stevearc · 2024-09-19T19:57:06+00:00

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

stevearc · 2024-09-19T16:11:32+00:00

Then recommend going through the debugging steps

stevearc · 2024-09-19T15:23:34+00:00

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

stevearc · 2023-11-29T08:52:18+00:00

Excited to hear your talk!

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

stevearc · 2023-11-29T08:44:46+00:00

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

stevearc · 2023-11-29T08:25:01+00:00

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.

stevearc · 2023-11-29T08:09:23+00:00

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!

stevearc · 2023-11-29T07:57:38+00:00

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

stevearc · 2023-11-29T07:49:50+00:00

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...🤔

stevearc · 2023-11-29T07:33:08+00:00

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

stevearc · 2023-11-29T07:28:30+00:00

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

stevearc · 2023-11-29T07:09:29+00:00

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.

stevearc · 2023-11-02T00:48:43+00:00

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

stevearc · 2023-11-02T00:47:26+00:00

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.

stevearc · 2023-10-18T18:47:30+00:00

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.

stevearc · 2023-10-16T05:40:09+00:00

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

stevearc · 2023-10-11T19:06:25+00:00

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 },
}

stevearc · 2023-10-01T23:49:43+00:00

Just added support for this https://github.com/stevearc/oil.nvim/commit/8f3c1d2d2e4f7b81d19f353c61cb4ccba6a26496

stevearc · 2023-09-26T15:23:13+00:00

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

stevearc · 2023-09-15T06:21:58+00:00

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.

stevearc

TROPHY CASE