Open oakes opened 9 years ago
If the Neovim process is a child of the GUI process, shoud it stop by itself when its parent dies ?
It is indeed a child process, but it isn't killed automatically. See this discussion, which seems to suggest that there is no cross-platform way to ensure a child process is killed when its parent exits.
If you communicate with Neovim using stdio(--embed cli flag), Neovim will exit when the parent dies.
For other types of connection, this could be fixed if Neovim had a ChannelClosed
autocmd: au ChannelClosed [ui_channel_id] wqa!
.
The reason I'm not using --embed
is because VteTerminal uses stdin/stdout to display it. Perhaps that could change if I began using a DrawingArea widget like python-client. I recall you were writing a version of that in C, correct?
I recall you were writing a version of that in C, correct?
I had plans to do it, but didn't start anything yet.
@tarruda I'm considering trying to implement ui.h
directly so I don't need to run neovim in a separate process. I figure it should be possible if I use a DrawingArea the same way you did, and run Neovim in a separate thread. Do you have any advice on how to do this? Should I somehow directly replace the ui.c
functions with my own? Rust is able to export functions so they can be used from C, but this type of monkey-patching is new to me.
@oakes I'm currently refactoring the event/UI subsystems to allow this(neovim/neovim#2371). The terminal UI is called directly because it runs in the same thread, but soon I will make some changes that will require the UI functions to run in a separate thread like a GUI toolkit, so it will be much simpler to do what you want.
Great, I was wondering if my idea might have threading problems so I'll follow that issue. I have temporarily stopped rebasing my fork on the latest Neovim commits, however, because I noticed api_free_array
started crashing. I believe I tracked it down to this commit, but haven't found the time to investigate further yet -- it could be something I'm doing wrong in neovim-rs. Anyway, once I solve that, I'll be ready to get those incoming changes.
Great, I was wondering if my idea might have threading problems so I'll follow that issue. I have temporarily stopped rebasing my fork on the latest Neovim commits, however, because I noticed api_free_array started crashing. I believe I tracked it down to this commit, but haven't found the time to investigate further yet -- it could be something I'm doing wrong in neovim-rs. Anyway, once I solve that, I'll be ready to get those incoming changes.
We must allow library users to pass pointers to malloc
, realloc
, calloc
and free
implementations so it's possible to pass memory from/to neovim(which now uses jemalloc by default, but without redefining the standard allocator symbols)
I am indeed using malloc in one place, so I take it that all I need to do is use je_malloc
instead? Either that, or disable jemalloc, I suppose.
Yes, but ideally we'd have a function that allows the library user to override the allocation functions used by nvim
We need a way to make the Neovim process shut itself down if the GUI doesn't shut down cleanly.