echasnovski / mini.nvim

Library of 40+ independent Lua modules improving overall Neovim (version 0.8 and higher) experience with minimal effort
MIT License
5.21k stars 187 forks source link

mini.run: simple run configs manager in your editor #1123

Open clorl opened 2 months ago

clorl commented 2 months ago

Contributing guidelines

Module(s)

mini.run

Description

One of the most basic features of most code editors or IDEs is running your code from the editor and getting back the errors. Yet, there aren't many popular or simple options to do this in neovim apart from overseer.nvim.

Features :

Bonus:

I think this idea really fits into mini's philosophy of small, straightforward and simple plugins, and probably fills a void in the neovim plugin ecosystem. I am willing to try and make a PR for a MVP of that new module.

echasnovski commented 2 months ago

Thanks for the suggestion!

I think most of the features will be spread across 'mini.terminals' (like open terminal and run command/selection in terminal) and 'mini.quickfix'. Nevertheless, this is a useful and quite comprehensive set of features to use as reference, thanks!

clorl commented 2 months ago

Thanks for the quick reply. Just wanna add that mini is probably my favorite neovim plugin I love the philosophy and simplicity.

It's up to you in the end to choose where this feature fits! I've been looking towards solving this issue for my personal config and thought it might fit mini's philosophy.

The real killer features that are missing everywhere to me are :

Hope that helps, will happily make a PR if I can be of use

matu3ba commented 2 months ago

Even overseer.nvim has significant problems for more advanced things like

  1. storing and validating outputs, https://github.com/stevearc/overseer.nvim/issues/230
  2. ui issues around shortcuts for tasks https://github.com/stevearc/overseer.nvim/issues/225
  3. doing dependency logic as system runtime constrain of the runner

and overseer has lots of error-prone callback logic.

I'd argue dependency things belong into a build system describing how the test runner REPL should work and patching around this via configurations leads to arbitrary complexity.

From my point of view the only advantage without huge complexity would remain to be project local run steps to get them into quickfix and/or dynamic attaching of debugger and offer a programming API to get the log streamed by user specified function to a neovim buffer. Common per language things could thereafter be collected in a wiki for copy-pasting.