!HCjHPBLFfoFpYNgwdE:matrix.org

Neovim dev

209 Members
Discussion about Neovim development and adjacent topics14 Servers

Load older messages


SenderMessageTime
1 Nov 2024
@clason:matrix.orgclasonyou know the (hard) constraints now.17:10:52
@ofseed:matrix.orgYi
In reply to@lewis6991:matrix.org
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.
I am indeed avoiding using C to solve this problem, not only because Lua is more supervised, but also because I think C cannot/difficult to solve some problems as I mentioned above. However, if using Lua cannot solve the problem, I will try using C and will not insist on implementing it in Lua.
17:13:20
@clason:matrix.orgclasonIt sounds to me like this is driving suboptimal solutions.17:14:11
@clason:matrix.orgclason we already have a translation layer (in C), which is just limited (so far). 17:15:36
@clason:matrix.orgclasonso the solution should be to extend that rather than create a second layer17:15:54
@ofseed:matrix.orgYiOkay, if C is the more preferred method.17:17:16
@clason:matrix.orgclasonyes, because that's where the code already lives17:17:37
@clason:matrix.orgclasonnot because of C vs. Lua17:17:49
@clason:matrix.orgclason(in fact, we'd prefer Lua if it was a clean slate; but it's not)17:18:04
@ofseed:matrix.orgYiBecause the third solution I can think of (using Lua) should be very messy to implement (with a lot of type checks or whether there is a metatable)17:18:56
@ofseed:matrix.orgYiSo it might still be C17:19:13
@lewis6991:matrix.orglewis6991We already have a solution it just happens to require a bit of C. Lua is an embedded language after all.17:19:43
@lewis6991:matrix.orglewis6991 * 17:20:01
@ofseed:matrix.orgYi* Because the third solution I can think of (using Lua) should be very messy to implement (with a lot of type checks or whether there is a metatable), and that's why I avoid implementing it.17:20:26
@mfussenegger:matrix.orgMathias For what's worth, the plan to move state that's currently local/internal to a public vim.b still doesn't sound very appealing to me. 18:46:00
@lewis6991:matrix.orglewis6991Good point, I agree. A lot of the data of these modules don't need to be so freely exposed. I think a better route would be to just consolidate what we already have internally, and refactor it into something a little more general.19:06:51
2 Nov 2024
@ofseed:matrix.orgYiThe public API is not my goal, but I find the current management of the buffer variable (in the inlay hint) difficult to refactor in a more general way; and this current method may be more suitable as a public API.01:45:38
@ofseed:matrix.orgYiPerhaps I should first try to apply the method in this PR specifically to inlay hints, keeping it internal only would be better?01:47:02
@ofseed:matrix.orgYiI might start with a brand new feature. I previously tried to apply the state management strategy to document highlighting, but the outcome of the discussion was that the state management issue should be addressed first.02:11:08
@ofseed:matrix.orgYiAlthough this may seem like going in circles, implementing a brand new feature should avoid any potential regressions.02:11:34
@sciguy:matrix.orgTravis d joined the room.12:33:19
3 Nov 2024
@tris203:matrix.orgtris203

With the recent lsp handler rewrite in mind, I am working on a plugin for razor (c# web) by re-implementing the logic from the Vscode extension. The way it works is by generating virtual docs with the c# and html in it, then attaching appropriate LSPs to those virtual buffers.

Then the 'main' LSP maps ranges, makes sub requests, and maps the result ranges.

Is there a place that I can hook just the lsp request/response so that if people have individual display over rides I don't overwrite them?

15:03:40
@lewis6991:matrix.orglewis6991you can wrap client.request15:44:42
@tris203:matrix.orgtris203Redacted or Malformed Event16:59:21
@tris203:matrix.orgtris203
               ``` local req = client.request
                client.request = function(method, params, handler, tbufnr)
                    if wrapper_func[method] then
                        return req(method, params, wrapper_func[method], tbufnr)
                    end
                    return req(method, params, handler, tbufnr)
                end```
20:03:20
@tris203:matrix.orgtris203 *
               local req = client.request
                client.request = function(method, params, handler, tbufnr)
                    if wrapper_func[method] then
                        return req(method, params, wrapper_func[method], tbufnr)
                    end
                    return req(method, params, handler, tbufnr)
                end```

do you mean something like this?

20:03:48
@tris203:matrix.orgtris203because in the overwritten handler, I have to make my own call to dispay, jump etc. which means if the user has it overwritten I dont know about it20:07:59
@lewis6991:matrix.orglewis6991Overwriting the handlers is deprecated now. If you need your own display then you should just issue your own request too and provide a high level function for users to call.20:28:17
@lewis6991:matrix.orglewis6991

Or overwrite the existing vim.lsp.buf func

20:28:34
5 Nov 2024
@seanpoo:matrix.org@seanpoo:matrix.org joined the room.13:18:42

Show newer messages


Back to Room ListRoom Version: 10