Not using local .jaq.json file
EricHenry opened this issue · 5 comments
Hey!
I am having trouble getting the local .jaq.json
file to be picked up by jaq. The file looks like
{
"internal": {
"lua": "luafile %",
"vim": "source %"
},
"external": {
"rust": "cargo run --features debug"
}
}
When I run the command inside of neovim, the default rust command that I have setup in my nvim config is used. (cargo run
). Any help would be appreciated, thanks!
Does running :lua print(vim.fn.expand('%:p:h'))
print the CWD
?
it prints the current working directory of the file that I have open. In my case its rust-project/src
. Where my .jaq.json
file is in rust-project/
. If I move the .jaq.json
file into the rust-project/src/
directory it works as expected, which is good!
Though I would expect the file to live at the root of the project folder instead of where my current open buffer is. Is that the intended design? I would love to contribute back to the project if this is not the expected behavior.
Though I would expect the file to live at the root of the project folder instead of where my current open buffer is. Is that the intended design?
The intended design is read from a .jaq.json
file located in the same directory as the current file. I find that determining the root of the project folder is somewhat as different directory structures can change depending on the framework/language.
I'll try to come up with a way around this limitation but in the meantime, you could symlink rust-projcet/.jaq.json
to rust-project/src/
with ln -s
.
The intended design is read from a .jaq.json file located in the same directory as the current file. I find that determining the root of the project folder is somewhat as different directory structures can change depending on the framework/language.
yeah that is a great point. Would looking for common top level dot files be a decent heuristic to use? Like .git
I'll try to come up with a way around this limitation but in the meantime, you could symlink rust-projcet/.jaq.json to rust-project/src/ with ln -s
Thank you! Good idea for a workaround 👍 .
Would looking for common top level dot files be a decent heuristic to use? Like .git
That's actually a pretty smart work-around. I'll try to get it working ASAP.