Comments (4)
I added a new API to override how the headless instance is spawned. It allows you to filter arguments and environment variables before it gets passed to the child instance like you proposed. The handle to the instance has to be returned by the callback.
For example:
require"osv".on["start_server"] = function(args, env)
-- do something with args and env, args is a table and env is a dict
return vim.fn.jobstart(args, {rpc = true, env = env})
end
I will close this for now, let me know if something else could be done.
from one-small-step-for-vimkind.
Thanks!
I was skimming over the source just now. I haven't tried it out yet, but I think 5417de4 fixes the recursive process spawn issue. But I'll let you know if I run into this again.
from one-small-step-for-vimkind.
Oh, it seems that nvim -u NONE -i NONE -n +'=require"osv".launch({port = 8086})'
isn't working either. This might just be the same issue that I was experiencing last time in #37 (having to do with argv getting copied and reused in child processes recursively). I suppose that launching this plugin simply isn't supported via cli args. If that's the case, maybe we should document it?
Edit: just confirmed that this is indeed the issue as the following works just fine as a workaround:
VIMINIT='=require"osv".launch({env = {VIMINIT = ""}, port = 8086})' nvim --headless -i NONE -n
Other ideas:
- Filter argv before passing it on
- Even better: somehow blacklist functions which spawn processes (such as
osv.launch()
) so that they return immediately if called within a nested/child process. To signal this, maybe we could just set an env var or something (which will be checked insidelaunch()
and any other such funcs). Although, this wouldn't keep other cli args (e.g.-c lua ...
or-c luafile ...
etc.) from running in nested instances.
...or maybe I'm just going about the whole thing wrong lol.
Also is there a way to make launch()
wait for a connection before returning?
from one-small-step-for-vimkind.
Good debugging of the issue. I haven't thought about it too much but at the moment the environment variable solution seem to be the most flexible. Maybe another way because I think this usecase is very specific and only people really knowing the inner working would use it, we should provide a solution so it doesn't affect the general usecase. I was thinking about adding a function to check if the server is already running so you can early exit in that case in the lua commands. How does it sound?
EDIT: Actually, this function is already implemented require"osv".is_running()
but it is also true that an environment variable solution would avoid the hassle you had and provide an easier solution. On the other hand, like you say, it doesn't completetly solve the problem as it will still run other lua commands. In the end, the perfect solution would be no configuration from the user, and only spawn an embedded neovim instance without such recursive calls. But how to differentiate lua commands which are used to spawn the neovim instance itself and lua commands for the headless debugging instance?
from one-small-step-for-vimkind.
Related Issues (20)
- Cannot launch with another rpc client HOT 4
- No response or event received HOT 3
- Get error when restart session HOT 1
- Evaluation only displays an empty rectangle HOT 6
- Plugin does not support wrapped `nvim` executable? HOT 6
- nvim gets spawned recursively? HOT 4
- Repl evaluate doesn't have access to function upvalues HOT 2
- Frames for pre-compiled sources report wrong path/line/column HOT 4
- Debugger couldn't connect to 127.0.0.1:8086: ECONNREFUSED while debugging lazy plugins HOT 2
- Stdout (print, io.write) doesn't seem to work HOT 4
- Fix inspect variable with tables in nvim-dap
- [BUG] Attaching to running instance doesn't work (fzf-lua) HOT 18
- require"osv".launch({port = 8086}) E5108: Error executing lua Vim:Error invoking 'nvim_exec_lua' on channel 18:
- Cannot launch `osv` at the beginning of a neovim configuration HOT 6
- Connect OSV to Plenary test harness HOT 3
- osv Freeze nvim after `:lua require"osv".run_this()` on NVIM v0.11.0-dev-19+g0f4f7d32c HOT 3
- Dependency requirements? HOT 4
- Vimscript function must not be called in a lua loop callback
- Can't start lua debugger on init.lua HOT 7
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 one-small-step-for-vimkind.