Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bug: diagnostics only being produced on task restart #334

Open
CooperCarnahan opened this issue Jul 29, 2024 · 0 comments
Open

bug: diagnostics only being produced on task restart #334

CooperCarnahan opened this issue Jul 29, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@CooperCarnahan
Copy link

Neovim version (nvim -v)

10.1 (release)

Operating system/version

Windows 11

Describe the bug

Running a task using OverseerRun does not produce diagnostic output, but restarting that same task (OverseerTaskAction->restart) produces diagnostics.

image

What is the severity of this bug?

breaking (some functionality is broken)

Steps To Reproduce

  1. Create a 'vscode-like' tasks.json file with the contents from the example file
  2. Create a main.c file with the contents from the example file
  3. nvim -u repro.lua
  4. Run OverseerRun->GCC Build
  5. Run OverseerOpen and check diagnostics for the task (should be empty)
  6. Re-run the task using OverseerTaskAction->restart
  7. Check diagnostics for the task (should have an error)

Expected Behavior

Running a task should produce a list of diagnostics which are displayed in the task list window that can be sent to the quickfix list.

Minimal example file

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "GCC Build",
      "type": "shell",
      "command": "gcc",
      "args": [
        "-g",
        "main.c",
        "-o",
        "main.exe"
      ],
      "group": {
        "kind": "build",
        "isDefault": true
      },
      "problemMatcher": "$gcc",
      "detail": "Task to build the active C/C++ file using GCC"
    }
  ]
}

main.c

#error "THIS IS AN ERROR"
int main(int argc, char *argv[]) { return 0; }

Minimal init.lua

local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({
    "git",
    "clone",
    "--filter=blob:none",
    "--single-branch",
    "https://github.com/folke/lazy.nvim.git",
    lazypath,
  })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  { "stevearc/dressing.nvim", config = true },
  {
    "stevearc/overseer.nvim",
    config = function()
      require("overseer").setup({
      })
    end,
  },
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")

Additional context

I've noticed when comparing the buffer window output of the working version (with diagnostics) versus the failing version (without diagnostics) that the failing version appears to have additional line breaks in weird places as well as a bunch of extra blank spaces and newlines at the end of the buffer. Not sure if this has any relation or not.

Occasionally (less than 10% of the time probably) the running the task works just fine and produces diagnostics as expected. No idea why it works some of the time and not at other times.

Have tested this same setup on a separate Windows 11 device running the same NVIM release and had similar results.

@CooperCarnahan CooperCarnahan added the bug Something isn't working label Jul 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant