Comments (17)
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.
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.
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.
If I implement something like this, I think it's more likely that I'll do it as described in #27.
from yabs.nvim.
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.
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.
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.
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.
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.
That looks great! I'm looking forward to using it!
from yabs.nvim.
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.
@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.
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.
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.
Thanks!
I will test this when I get a chance.
from yabs.nvim.
@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.
@Dekker1 great, thanks!
from yabs.nvim.
Related Issues (20)
- Proper Vim integrated documentation
- Lets start a wiki with good defaults for popular languages HOT 9
- output to `vim.diagnostic` module HOT 9
- Customize where the quickfix opens HOT 2
- Some suggestions
- Suggestion: Allow running outputed binary as an independent application HOT 2
- Documentation / Example of how to use .yabs files HOT 1
- quickfix output doesn't work in windows 10 HOT 15
- Automatically get project local tasks from cmake/make/just etc HOT 7
- Running dependent tasks based on the result of the task HOT 1
- Proposal: Genrate a default .yabs HOT 3
- Proposal: Root markers & Run commands in specific directories HOT 1
- Proposal: Run command on condition
- Chained task produces nvim errors, doesn't carry out fully if the first task's output is set to `terminal` HOT 7
- "vimL function must not be called in a lua loop callback" HOT 2
- [rewrite] default runners and outputs HOT 3
- nvim_buf_get_option must not be called in a lua loop callback HOT 2
- Define tasks in a file HOT 1
- How to config the yabs.nvim echo some hints after command is done?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yabs.nvim.