fn-based tool tests manually construct commands

[barrettruth]

Problem

Four tools use custom fn in their configs, so their tests can't use the
run_fmt/run_lint helpers and must manually invoke the tool via
vim.system. This means the tests don't exercise the actual config definition
and could drift from what guard.nvim runs in practice.

Affected tools: prettierd, cpplint, checkmake, zsh

Possible solution

Either extend the test helpers to support fn-based configs (e.g. by calling
the fn directly with a mock buffer), or accept these as the only exceptions
to the "always use run_fmt/run_lint" rule and document them as such.

[barrettruth]

checkmake and prettierd were converted to standard configs in #81. cpplint and zsh can't be b/c they write diagnostics to stderr and exit non-zero, which guard.nvim's exec_linter treats as a fatal error instead of passing to parse.

If you recall, I opened guard.nvim#248 to add stderr/ignore_exit_code fields but it was closed b/c of the existence of ADVANCED.md as you know.

Long story short, I don't think this is the right decision for the following reasons:

1. It reduces user adoption. none-ls and conform.nvim both handle stderr-based linters transparently in their standard config format. Asking users to write coroutine logic (which, after 6 years of using common nvim plugins, I have NEVER seen until now) for a quite common linter pattern (cpplint, zsh -n, shellcheck, pyright, etc.) is a real barrier.
2. It impedes testing. run_lint can't exercise fn-based configs, so cpplint and zsh tests have to manually construct vim.system calls and feed the output to parse()
3. While not an actual reason, it also doesn't hurt that the solution is trivial.

This also brings up another question: promotion. I truly think guard.nvim has the most elegant and easily configurable solution to formatting and linting, not to mention the unique async approach.

I'd like to make a second "push" for guard.nvim and guard-collection, including reddit posts and this-week-in-neovim plugins to increase adoption. Perhaps a new release an announcement would do the trick.

I know these are two separate issues, but I do think the first one, with respect to UX, does tie into the second one.

What do you think?

@xiaoshihou514

NOTE: also adding @glepnir here too. If you recall, I used to work on guard.nvim and guard-collection, then faded out of the mix. Please see my recent changes to CI here which demonstrate my commitment to the project!

[xiaoshihou514]

Thanks for the detailed write-up. I appreciate your passion for the project and the valid points you've raised regarding user adoption and testing.

However, I'd like to explain why the current approach is intentional and why I believe it aligns better with the long-term vision of guard.nvim.

Regarding the barrier to entry, I completely understand your concern. However, the core identity of guard.nvim is to remain a lightweight solution. We intentionally avoid adding specific fields like ignore_exit_code because that path often leads to bloat. Many mainstream plugins become heavy precisely because they accumulate endless configuration flags to cover every edge case. By relying on functions, we provide a "Swiss Army knife" approach: a single, powerful mechanism that solves all problems without cluttering the API.

You mentioned that the solution is "trivial" to implement. While that might be true for this specific case, the issue is about the precedent it sets. If we add this option today, what happens when the next user needs ignore_specific_stderr_pattern? Or retry_on_failure? If we start down this path, we will inevitably end up merging more and more specific options. This will lead to codebase bloat and maintenance hell, which is something I really want to avoid.

Regarding testing, I actually touched on this in the PR review. We should achieve painless testing by mocking the coroutine-related functions. It's true that this isn't the most elegant solution, but it allows us to test the code in a way that mimics real-world scenarios. This provides a more comprehensive test coverage than the current setup, ensuring the tool works as expected in actual usage.

I hope this clarifies my stance. I told the ai to summarize all my points in a writeup.

PS: I did notice that your user name's familiar, but thought it was a coincidence since it's not the same account. I guess you finished your studies? :)

[barrettruth]

Fixing #81 based on this feedback.

Thoughts on a new release + promotion in r/neovim?

Also, my username used to be barrett-ruth with a peanuts snoopy pfp. had a change of identity. And I am partially depriving myself of my studies with some of these prs 😂

[xiaoshihou514]

There's release actions on the core repo for every commit, but a 3.0 is probably far away.

Promotions... I don't have much opinions on those, guard was released a bit before null-ls' archival, so there were a bunch of users at that time, after that there's not that much activity in terms of issues or prs. Feel free to promote if you want. (Isn't twin dead tho?)

[barrettruth]

TWIN is dead.