Code Monkey home page Code Monkey logo

Comments (17)

Dekker1 avatar Dekker1 commented on May 8, 2024 2

The error occurred when running this configuration:

	require("yabs"):setup {
		languages = {
			cpp = {
				default_task = "cmake_build",
				tasks = {}
			},
		},
		-- Default tasks
		tasks = {
			cmake_build = {
				command = "cmake --build build --config Debug",
				condition = require("yabs.conditions").file_exists("CMakeLists.txt"),
				output = "quickfix",
			},
			cmake_build_rel = {
				command = "cmake --build build --config Release",
				condition = require("yabs.conditions").file_exists("CMakeLists.txt"),
				output = "quickfix",
			},
			cmake_configure = {
				command = "cmake -B build -S .",
				condition = require("yabs.conditions").file_exists("CMakeLists.txt"),
				output = "quickfix",
			},
			cmake_clean = {
				command = "cmake --build build --target clean",
				condition = require("yabs.conditions").file_exists("CMakeLists.txt"),
				output = "quickfix",
			},
		},
	}

from yabs.nvim.

Dekker1 avatar Dekker1 commented on May 8, 2024 1

@pianocomposer321

The posted issue was merely my first try at using the PR mentioned above. The issue was later resolved in the PR. I don't think there was really any issue here anymore.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

Interesting idea...I'm not exactly sure how to go about implementing it, but I'll think about it.

Thanks for the suggestion!

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

If I implement something like this, I think it's more likely that I'll do it as described in #27.

from yabs.nvim.

Dekker1 avatar Dekker1 commented on May 8, 2024

Although I agree that the from key suggested in #27 would be great for other abstract build automation tools such as make, but are not as relevant for tools that do not define custom tasks. Tools such as prettier, black, pylint, clang-format (i.e., formatters and linters) generally only have one or two predefined tasks and their usage is generally detected using the existence of a configuration file.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

Ok, I think I understand a bit better now.

Would the ability to disable or reenable tasks based on certain conditions satisfy your request (maybe along with a default or two making it easier to do thing such as detect certain files)?

For example, you could have a disable keyword that would be a function, and if the function returns true, that task would be disabled.

from yabs.nvim.

Dekker1 avatar Dekker1 commented on May 8, 2024

Yes, I think that would probably work. (I would probably prefer to work the other way around and have an enable keyword to err on the side of caution, but that's probably just personal preference).

The key question does become when you actually execute the functions in the key. You could execute the function every time you load/inspect the tasks, but that might be overkill since the file will not often change. I'm not really sure how much of an obstacle that is.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

Here's what I'm thinking:

I need to rework how the config file works. Currently, it's just a lua file and to load the config I run dofile. That is very hacky however, and causes some problems with that file manipulating the state but it not being updated after where it was called from. I'm thinking that instead what I need to do is have that config file just return the config options in a table (basically the same thing as what you would pass to yabs:setup()). This would be a breaking change, but it would make things a lot easier, and I think it's best to do it sooner rather than later. There are already a number of people asking about how to use the config file, so I'd rather change this before answering them, if that makes sense ;).

Then, once that's changed, it will be a lot easier to do things with the config file that manipulate the state. ATP I'm thinking I'll just have it run the function in yabs:setup(), right after everything is loaded. Each disable function should only need to run once, when that task is added, because I don't see any good reasons to have it enabled during part of the session but not for another part. Most of the conditions will be based on the cwd I think, and I think users should be able to figure out how to manage that themselves. There are plenty of plugins that work this way.

The one potential issue I anticipate being a problem is if someone doesn't start neovim from their desired cwd, and instead use something like vim-rooter. That will be a problem if yabs is loaded before vim-rooter changes the cwd.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

Disabling tasks based on a condition was just added in the feature branch.

Here's how you would use it:

require("yabs"):setup {
  tasks = {
    test = {
      command = "echo testing 1 2 3"
      condition = function()
        return true  -- or false
      end
    }
  }
}

The task will only be available if the condition is a function that returns true. This function is run once, when the task is first added to the list. If a task is disabled, it will not show up in the telescope picker.

Additionally, I'm providing one builtin condition out of the box, file_exists, which will simply return true if the file exists, and false if it doesn't:

require("yabs"):setup {
  tasks = {
    run = {
      command = "make run"
      condition = require("yabs.conditions").file_exists("Makefile")
    }
  }
}

from yabs.nvim.

Dekker1 avatar Dekker1 commented on May 8, 2024

That looks great! I'm looking forward to using it!

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

Could you check out the PR and make sure it works as expected? I'd like to write the docs and get it merged, but it's always better to have a second pair of eyes check it over first 😉.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

@Dekker1 have you been able to take a look at the PR to make sure it provides what you are asking for?

from yabs.nvim.

Dekker1 avatar Dekker1 commented on May 8, 2024

My apologies for the slow reaction, the last few days have been rather busy. I played around with it today and it seems to work very well. The only thing that I seem to be struggling with is the default task. I had previously set the default task to be the build task and bound it to a key to be able to do that quickly. However, providing the default task globally does not work unless I know what task will be available. Trying to do it on the language level gives an error:
invalid task "cmake_build" for language cpp

I can think of two solutions: being able to provide an hierarchy of default tasks of which the first available task is chosen, or otherwise being able to provide a function for the value of the default task.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

Thanks for responding!

Could you provide an example of a config that throws that error? It'll be easier to fix the problem if I have a test case to run against 😉.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

Thanks!

I will test this when I get a chance.

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

@Dekker1 Sorry I haven't responded sooner...I actually completely forgot about this issue for a while. If I am reading your example config correctly, it looks like you only have the cmake_build task set to run for cpp files. If that's what you want, I would suggest moving all of the cmake_ tasks from the top-level tasks table to the cpp.tasks table. The reason you're currently getting the error is because the default_task option looks for tasks under the table that the key is in, which is the cpp language in this case. The tasks aren't defined there though, so that's why there's the error.

Alternatively, if you want the tasks to be available for all filetypes in that project, you can move the default_task key from cpp to the top-level tasks table. If you want this to be the case only for a specific project and not globally, you can use a .yabs file.

LMK if this fixes it. If it doesn't I'd appreciate it if you could open a separate issue, because I'm less likely to forget about it if the issue is open, and I'd rather not reopen this one for a separate issue.

Thanks!

from yabs.nvim.

pianocomposer321 avatar pianocomposer321 commented on May 8, 2024

@Dekker1 great, thanks!

from yabs.nvim.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.