Automatically get project local tasks from cmake/make/just etc

[IndianBoy42]

(btw https://github.com/casey/just)

the .yabs file is interesting but its specific to this plugin, a more compatible method would be to gather tasks from common build systems.

cmake, make, just, npm, meson, etc

All this commands should have some way of running them to get a list of targets/tasks. We could create an even more flexible system where users register commands to run and some simple parsing function to extract a list of tasks and commands.

What do you think about this idea?

[pianocomposer321]

It's an interesting idea, but I'm not sure it really fits that well into this plugin's intent. One of the things that I decided early on in the creation of this plugin is that I wanted the focus to be on making it easy for users to define their own commands, not on having a set of predefined ones that's supposed to be "exhaustive". I want to be the maintainer of the functionality of this plugin, not the maintainer of a million different ways of interacting with a million different preexisting build systems, 95% of which I've never even heard of. I don't want to be flooded with issues constantly telling me that "X build system is broken with recent update" or "Y build system now has this new feature, can it be supported", etc.

You said that having this functionality would make this plugin even more flexible, but unless I'm misunderstanding what you're requesting, it seems to me that it would have the opposite effect - I would be so busy supporting preexisting frameworks, as well as adding new ones as they come out, that the focus would shift away from the flexibility of being able to add your own if you want to. Instead of being a plugin for users to define their own tasks, it would be a collection of tasks that are already available, and if yours isn't on the list, well, you'll just have to open an issue and wait your turn. That's what I'm trying to avoid.

So instead, I think it's better to keep it how it is, but I think that adding a wiki with some examples is a great idea.

I do have some defaults included, but, first of all, none of them are tasks, all of them are outputs, and second of all, I intentionally am only including ones that I think will be useful for basically anyone who uses this plugin. That means I'm only using vim features, such as quickfix lists, buffers, etc., and not for example a tmux pane. If the user wants that, they can implement it themselves, and if they want to, add an example for others to follow in the wiki. But that's not my focus, because I know that not everyone uses vim with tmux.

I hope that makes sense.

Unless I completely misunderstood what you're asking, I don't think it will happen. So unless you have something else to add, I'll be closing this.

[pianocomposer321]

P.S. I took a look at just though, it does look pretty cool. I might actually end up using it, as I've had a hard time with writing my own makefiles and this looks like a nice alternative.

[pianocomposer321]

Also, seems like it might be a dup of https://github.com/pianocomposer321/yabs.nvim/issues/23.

[IndianBoy42]

Well my idea in the last paragraph is not to build in the cmake/make/etc targets, but have something like:

tasks = {
   {
      from = "ninja -t targets" -- Gets list of targets from ninja
      parser = function(lines)
          -- Return a list of task definitions by parsing the output of the command
      end
   }
}

Then YABS would just run that command and parser to get a list of tasks. That way the user can use whatever build system they want

[IndianBoy42]

So this way as you said you wouldn't have to maintain the definitions for any build systems (maybe have a wiki for common ones like I mentioned in another issue)

[IndianBoy42]

Also I just realised make actually doesn't have a way to get a list of targets, which is really annoying, the main solution seems to be grepping the Makefile, which... ugh. (https://stackoverflow.com/questions/4219255/how-do-you-get-the-list-of-targets-in-a-makefile)

[pianocomposer321]

Interesting idea...that actually sounds like a nice feature to have. No promises about when or how, but I'll definitely think about it.