!HCjHPBLFfoFpYNgwdE:matrix.org

Neovim dev

209 Members
Discussion about Neovim development and adjacent topics14 Servers

Load older messages


SenderMessageTime
7 Nov 2024
@bfredl:matrix.orgbfredllike they cannot declare dependencies like dynamic libs can22:03:32
@shadowwolf_01:matrix.orgsmolck

okay so:

  • have a libnvim.h or whatever file with a bunch of ui_event_name_yourmom(..) function declarations
  • include this file in main.c or wherever but also include another header that actually defines these functions, so no issues on the neovim binary side of things
  • then when the static library is built, since you won't be including the header that implements these functions on the neovim side, it will only compile when you include that header if you also include a header defining the symbols, or you define them in the file you include it with

that all correct?

22:04:57
@shadowwolf_01:matrix.orgsmolck *

okay so:

  • have a libnvim.h or whatever file with a bunch of ui_event_name_yourmom(..) function declarations
  • include this file in main.c or wherever but also include another header that actually defines these functions, so no issues on the neovim binary side of things
  • then when the static library is built, since you as a user of libnvim won't be including the header that implements these functions on the neovim side, it will only compile when you include that header if you also include a header defining the symbols, or you define them in the file you include it with

that all correct?

22:05:12
@shadowwolf_01:matrix.orgsmolck *

okay so:

  • have a libnvim.h or whatever file with a bunch of ui_event_name_yourmom(..) function declarations
  • include this file in main.c or wherever but also include another header that actually defines these functions, so no issues on the neovim binary side of things
  • then when the static library is built, since you as a user of libnvim won't be including the header that implements these functions on the neovim side, it will only compile when you include that libnvim.h header if you also include a header defining the symbols, or you define them in the file you include it with

that all correct?

22:05:22
@shadowwolf_01:matrix.orgsmolck *

okay so:

  • have a libnvim.h or whatever file with a bunch of ui_event_name_yourmom(..) function declarations
  • include this file in main.c or wherever but also include another header that actually defines these functions, so no issues on the neovim binary side of things
  • then when the static library is built, since you as a user of libnvim won't be including the header that implements these functions on the neovim side, it will only compile when you include that libnvim.h header if you also include a header defining the handlers in your own project, or you define them in the file you include it with

that all correct?

22:05:32
@bfredl:matrix.orgbfredlyes, or it will be a link-time error to be precise22:06:30
@shadowwolf_01:matrix.orgsmolckright, yeah22:06:37
@shadowwolf_01:matrix.orgsmolckthat seem like a reasonable API we want to expose to users? or you think the vtable version is the better one?22:07:03
@shadowwolf_01:matrix.orgsmolckthis way is perhaps better but it feels somewhat hacky to me, or maybe a little too clever, but avoiding the indirection is I guess good? idk22:08:24
@shadowwolf_01:matrix.orgsmolck how much worse would it really be to just nvim_set_grid_flush_callback(...) etc. I wonder 22:09:34
@shadowwolf_01:matrix.orgsmolck oh also, I know neovim cares nothing about C++ so it's up to the user to deal with figuring that out, but 22:09:51
@shadowwolf_01:matrix.orgsmolckI really am trying to figure out how to make the including these headers in C++ more ergonomic without corrupting neovim with any cpp code22:10:37
@shadowwolf_01:matrix.orgsmolckI guess the user just has to write a C wrapper the same way other languages (except Zig lmao) would22:10:53
@zeertzjq:matrix.orgzeertzjq
In reply to @moonglade:matrix.org
Seems like vim-go uses noshellslash even for Linux
Yes, did you forget by comment?
22:55:30
@moonglade:matrix.orgFamiu
In reply to @zeertzjq:matrix.org
Yes, did you forget by comment?
I thought it only did that on Windows
22:57:27
8 Nov 2024
@echasnovski:matrix.orgechasnovski Famiu: There is a somewhat strange and inconsistent behavior on Nightly about "deprecated" options. 09:38:34
@echasnovski:matrix.orgechasnovski Those are the options that are listed in vim.api.nvim_get_all_options_info() but error (on 0.10.2) when trying to access their value through vim.o (vim.bo, vim.wo). 09:39:27
@echasnovski:matrix.orgechasnovski

Those are:

{
  "aleph",
  "browsedir",
  "completeslash",
  "guioptions",
  "guitablabel",
  "guitabtooltip",
  "imcmdline",
  "imdisable",
  "mouseshape",
  "opendevice",
  "pastetoggle",
  "shellslash",
  "termencoding",
}
09:39:59
@echasnovski:matrix.orgechasnovski Now they don't error (which is fine, I guess), but they return a not consistent values.
vim.o.aleph returns 224 (which is its Vim default), but vim.o.browsedir returns empty string while "last" is its default Vim value.
09:41:21
@zeertzjq:matrix.orgzeertzjq Did they not show up in nvim_get_all_options_info in 0.10.2? 09:41:24
@echasnovski:matrix.orgechasnovskiThey did.09:41:43
@echasnovski:matrix.orgechasnovski They errored when trying to access them with vim.o / vim.bo / vim.wo. Now they don't, but instead return some inconsistent values. 09:42:29
@echasnovski:matrix.orgechasnovski
In reply to @echasnovski:matrix.org
They did.
In fact, those are the only (as far as I can tell through script) options which are listed in nvim_get_all_options_info() in 0.10.2 but error when trying to access with vim.o and friends.
09:43:24
@echasnovski:matrix.orgechasnovski

Here is a script for future reference:

_G.option_errors = {}
for name, info in pairs(vim.api.nvim_get_all_options_info()) do
  local value_source = ({ global = 'go', win = 'wo', buf = 'bo' })[info.scope]
  local errors = pcall(function() return vim[value_source][name] end)
  if not errors then table.insert(_G.option_errors, name) end
end
table.sort(_G.option_errors)
print(vim.inspect(_G.option_errors))
09:52:07
@moonglade:matrix.orgFamiu
In reply to @echasnovski:matrix.org
Now they don't error (which is fine, I guess), but they return a not consistent values.
vim.o.aleph returns 224 (which is its Vim default), but vim.o.browsedir returns empty string while "last" is its default Vim value.
I think I know what's causing this
14:01:36
@moonglade:matrix.orgFamiuI'm honestly unsure if it should keep erroring or not14:04:46
@moonglade:matrix.orgFamiuOkay so14:06:50
@moonglade:matrix.orgFamiuI've figured this out14:06:52
@echasnovski:matrix.orgechasnovski This is more about an inconsistent returned values. 14:07:05
@moonglade:matrix.orgFamiu Now the behavior of vim.o is the same as &option 14:07:15

Show newer messages


Back to Room ListRoom Version: 10