Sender | Message | Time |
---|---|---|
1 Nov 2024 | ||
clason | you know the (hard) constraints now. | 17:10:52 |
Yi | In reply to@lewis6991:matrix.orgI 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 | It sounds to me like this is driving suboptimal solutions. | 17:14:11 |
clason | we already have a translation layer (in C), which is just limited (so far). | 17:15:36 |
clason | so the solution should be to extend that rather than create a second layer | 17:15:54 |
Yi | Okay, if C is the more preferred method. | 17:17:16 |
clason | yes, because that's where the code already lives | 17:17:37 |
clason | not because of C vs. Lua | 17:17:49 |
clason | (in fact, we'd prefer Lua if it was a clean slate; but it's not) | 17:18:04 |
Yi | 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) | 17:18:56 |
Yi | So it might still be C | 17:19:13 |
lewis6991 | We already have a solution it just happens to require a bit of C. Lua is an embedded language after all. | 17:19:43 |
lewis6991 | * | 17:20:01 |
Yi | * 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 |
Mathias | 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 | Good 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 | ||
Yi | The 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 |
Yi | Perhaps 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 |
Yi | I 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 |
Yi | Although this may seem like going in circles, implementing a brand new feature should avoid any potential regressions. | 02:11:34 |
Travis d joined the room. | 12:33:19 | |
3 Nov 2024 | ||
tris203 | 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 | you can wrap client.request | 15:44:42 |
tris203 | Redacted or Malformed Event | 16:59:21 |
tris203 |
| 20:03:20 |
tris203 | *
do you mean something like this? | 20:03:48 |
tris203 | because 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 it | 20:07:59 |
lewis6991 | Overwriting 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 | Or overwrite the existing | 20:28:34 |
5 Nov 2024 | ||
@seanpoo:matrix.org joined the room. | 13:18:42 |