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

fix(quickfix): auto_close_when_success false is ignored #234

Merged

Conversation

luxstudio90
Copy link
Contributor

When the runner/executor is set to quickfix and in the options auto_close_when_success is set to false, the quickfix window does not remain open.

This PR adds the missing check when success code = 0, auto close = false.

The issue is referenced also in the first bullet of #201 (comment)

When the runner/executor is set to `quickfix` and in the options
`auto_close_when_success` is set to false, the quickfix window does not
remain open.

This PR adds the missing check when success code = 0, auto close = false.

The issue is referenced also in the first bullet of
Civitasv#201 (comment)
@@ -73,6 +73,10 @@ function _quickfix.run(cmd, env_script, env, args, cwd, opts, on_exit, on_output
_quickfix.close(opts)
end, 100)
end
if code == 0 and not opts.auto_close_when_success then
_quickfix.show(opts)
_quickfix.scroll_to_bottom()
Copy link
Owner

@Civitasv Civitasv May 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When code equals 0, and auto_close_when_success is set to false, it should remain open. I don't see why should we add this block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be needed when the "Executor" has opts.auto_close_when_success = true and the "Runner" has opts.auto_close_when_success = false and both use quickfix.

If you run CMakeRun, the executor runs first, closing the quickfix window on success. Then the runner executes but the quickfix is closed by the runner and remains closed.

I can reproduce this all the time with the following config:

opts = {
    cmake_regenerate_on_save = true,
    cmake_generate_options = { "-DCMAKE_EXPORT_COMPILE_COMMANDS=1", "-GNinja" },
    cmake_build_directory = "build",
    cmake_soft_link_compile_commands = true,
    cmake_executor = {
      name = "quickfix", -- name of the executor
      opts = {
        show = "always",
        position = "belowright",
        size = 15,
        auto_close_when_success = true,
      },
    },
    cmake_runner = { 
      name = "quickfix", -- name of the runner
      opts = {
        show = "always",
        position = "belowright",
        size = 15,
        auto_close_when_success = false,
      },
    },
},

Can you check?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can reproduce this with this config. But the pr cannot fix it. I think the reason is from vim.defer_fn.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed. Using the following seems to do the trick:

if code == 0 and opts.auto_close_when_success then
  -- vim.defer_fn(function()
  _quickfix.close(opts)
  -- end, 100)
end

Is there a reason for the vim.defer_fn on close?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can remove this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed it. Behaviour is OK now.

Remove `vim.defer_fn()` when closing the executor/runner to avoid
synchronization issues.
@Civitasv Civitasv merged commit d84e9ec into Civitasv:master May 20, 2024
2 checks passed
@Civitasv
Copy link
Owner

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants