 | Neovim dev | 209 Members |
| Discussion about Neovim development and adjacent topics | 14 Servers |
| Neovim dev | 209 Members |
| Discussion about Neovim development and adjacent topics | 14 Servers |
| Sender | Message | Time |
|---|---|---|
| 1 Nov 2024 | ||
 clason | yeah, then the value proposition is much lower | 14:50:38 |
| clason | probably not worth it | 14:50:44 |
| clason | better approach would be to improve the bridge for tables (in C) along Justin's proposal | 14:51:23 |
| clason | threads and userdata are very low priority | 14:51:35 |
 lewis6991 |
No bueno | 14:51:46 |
 Yi | threads and userdata are very low priorityThe main purpose is tables (with metatables). userdata, and threads are supported as a sideline | 14:54:18 |
| clason | yeah, but then a more targeted approach is appropriate | 14:54:43 |
| Yi | No buenoEven now it cannot be used directly, so I think it maybe reasonable https://github.com/neovim/neovim/blob/7bf3a616e18205d353d9c4a44e8c2f885d700129/runtime/doc/lua.txt#L1227-L1238 | 14:58:23 |
| clason | In a nutshell:
| 14:58:27 |
| clason | these two things are not up for discussion | 14:58:37 |
| clason | which means the way forward needs to be in C | 14:59:06 |
| Yi | This breaking change may not happen; I will reimplement it tomorrow (leaving time for discussion) | 14:59:49 |
| lewis6991 | The only acceptable breaking change is that variables created in Lua are readonly to vimscript. | 15:04:22 |
| lewis6991 | So it will be breaking no matter what | 15:04:30 |
| Yi | To clarify further: The breaking change I mentioned is that the table created in vimscript using vim.b.foo can no longer be accessed in the same way as before (though there are still other read-only ways). The reason is that vim.b no longer attempts to convert Lua tables into Vimscript dictionaries, but instead saves them directly as Lua variables. This breaking change could be avoided, but IMHO the necessity of maintaining it is not very significant, because:
In simple terms, there must be Lua tables that cannot be completely converted into Vimscript dictionaries, even if implemented in C. Moreover, even though we can access dictionaries like b:foo using vim.b.foo now, it returns a copy, which means using vim.b.foo.bar = "value" is always a meaningless operation; it will not change b:foo.bar or anything else, which contradicts the idea of broadly using this API in Lua. So if a separate API for Lua variables(like what this PR does) is not added, this behavior will and should be broken. | 16:37:56 |
| clason | Yeah, that would be too breaking. Sorry. | 16:38:23 |
| clason | it need not be broken if the conversion layer in C is extended | 16:38:51 |
| clason | so this is the (one) way to do it | 16:39:00 |
| clason | The deal breaker is changing the behavior for tables that can be represented as dictionaries | 16:39:43 |
| clason | that is simply not acceptable | 16:40:49 |
| Yi | The deal breaker is changing the behavior for tables that can be represented as dictionariesDefinitely, but it may not be worth it | 16:42:06 |
| Yi | But I am not creating a problem and then trying to solve it. We do already have a mechanism for managing buffer-level variables, and my goal is to avoid it being invented over and over again and bugs being fixed repeatedly. | 16:44:50 |
| Yi | Any refactoring that unifies this mechanism without using vim.b can be seen as adding a separate API, which is unacceptable, as you said. | 16:45:53 |
| clason | But the crux here is that there is already a plan for how this should be done, and you're deviating from it. | 16:46:58 |
| clason | if your proposal was the only way to do that, things would be different -- but that's not the case. | 16:47:52 |
| clason | So we'd rather hold out for a proper solution, all things considered. | 16:48:06 |
| Yi | I think I have outlined several solutions here. The first is a standalone API (the code currently in the PR), the second would introduce a breaking change (it's easy to change but not implemented, and I discussed the issues it would bring here). I also have a third idea that tries to avoid breaking changes as much as possible, but it may have issues in terms of implementation, so I will demonstrate it later through code. | 17:00:20 |
| Yi | So we'd rather hold out for a proper solution, all things considered.This is what I am doing, because I won't know if it is acceptable before I express my first and second solution. | 17:02:44 |
| lewis6991 | It sounds like you are trying to shy away from making any changes in C and making a Lua only solution? If so, I don't think the read-only aspect for vimscript will be that hard. | 17:03:38 |
| clason | In reply to @ofseed:matrix.orglooking forward to it then | 17:10:43 |