Plenary test file command unceptioned

[James Trew]

Firstly, thanks for this plugin 🚀

Currently, and really I suppose this is really by design, plenary.nvim's testing functionality/test runner is getting blocked by unception.

Glancing at the implementation, it looks like it's running neovim in headless mode inside a floating window.

I'm aware I can simply start neovim with unception disabled in which case the testing runner works but I was wondering if it's possible to make some sort of exception.

[Samuel Williams]

Hello!

I'm not super familiar with plenary, but I glanced over the documentation, so maybe we can solve this together!

To recap, if unception is enabled, when Neovim is launched and the plugin is loaded, unception checks if Neovim is running in a nested terminal session. If Neovim isn't nested, the launched session becomes the host session, but if the session is nested, the file arguments are forwarded to the host and Neovim exits. I believe the latter could be what's happening here for the tests that plenary tries to run.

I'm aware I can simply start neovim with unception disabled in which case the testing runner works but I was wondering if it's possible to make some sort of exception.

Disabling unception altogether is definitely an option, but I think disabling it for the test sessions alone is probably the best way to handle this, and I imagine that it should work. It looks like in the section of plenary's README that you linked, it details ways to specify an init file for the tests that you're running. It looks like the "minimal" option runs the tests with the --no-plugin flag, which I'd think would do the trick, assuming that works for your use case.

A nested session without unception enabled should behave as vanilla Neovim would. For example, without disabling unception in the host session, I can still nest a Neovim session by opening a terminal buffer and running nvim --noplugin ./my_file.txt. Would you be able to check if leveraging those test options addresses the issue? I'm not sure that there's a robust solution that makes sense to implement on unception's end.

[Owen Pearson]

@samjwill Without knowing much about the inner workings of unception, would it not work to just ignore launches where the --headless flag is present (or at least allow this behaviour via an option)?

[James Trew]

It looks like the "minimal" option runs the tests with the --no-plugin flag, which I'd think would do the trick, assuming that works for your use case.

This seems to do the trick actually 😄
At least for my current test cases, having the minimal option doesn't negatively affect the tests.

would it not work to just ignore launches where the --headless flag is present (or at least allow this behaviour via an option)?

I do also like this idea if it's possible to implement. This feels like something that makes sense to me and could possibly help others with similar issues.

As for me, I'm pretty happy with minimal option solution and happy to close this issue or continue this discussion.

Very small tweak to my keymapping. For any future wanders that is:

vim.keymap.set(
  "n",
  "<leader>t",
  function()
    require("plenary.test_harness").test_directory(vim.fn.expand("%:p"), { minimal = true })
  end
)

[Samuel Williams]

The thought of adding a check to handle the flag had occurred to me, though I've been somewhat hesitant to implement handling logic for each command-line flag, as the more I look into it, the more it looks like a rabbit hole. I have some open issues marked as "enhancements" to look into handling a few others, but I had been putting them off until I could come up with a clean way to do so, and in the meantime, had more or less decided that they're out of scope (see the limitations section of the README).

However, if headless mode is something that's used commonly enough that it's causing people issues, I agree that it makes sense to handle, since there's a built-in function for checking availability of a UI and all that would be needed to restore the desired functionality is disabling unception.

Would either of you be willing to check out the feature branch in #54, and verify that it addresses the problem?

[James Trew]

#54 looks to be working well for me