| Time |
Nick |
Message |
| 00:00 |
MTDiscord |
<mark.wiemer> what do you mean when you say "both language servers"? LuaLS and luacheck? |
| 00:00 |
MTDiscord |
<greenxenith> What is the upper limit of expression? |
| 00:00 |
MTDiscord |
<a.corp.serot> in both of our cases, we wanted to write annotations as accurate as possible. |
| 00:02 |
MTDiscord |
<greenxenith> It is up to the post-processor to format the amount of expression a particular LS wants. It can omit info if it needs, or fill in dummy info where needed. The only thing we would consider doing is providing enough info to cover all posibilities, if we are nice |
| 00:03 |
MTDiscord |
<a.corp.serot> but you could really just let it be less accurate. "both language servers" mean emmylua and luals the upper limit of type expression is that you can't do most typescript interface stuff like making all fields of an interface/class required because there's no class field transformers |
| 00:04 |
MTDiscord |
<greenxenith> That seems like the type of info docs should have anyway (requried fields) |
| 00:04 |
MTDiscord |
<a.corp.serot> ideally, the new API spec should provide more information than what the LSes are capable of |
| 00:05 |
MTDiscord |
<a.corp.serot> but i won't force any promises |
| 00:05 |
MTDiscord |
<mark.wiemer> It is possible for a particular language server to not support many valuable features though, maybe that's what @a.corp.serot means? |
| 00:05 |
MTDiscord |
<greenxenith> I mean sure but that isnt relevant |
| 00:05 |
MTDiscord |
<greenxenith> Once again, that is a post-processor job |
| 00:05 |
MTDiscord |
<mark.wiemer> maybe EmmyLua doesn't support valuable features? Maybe LuaLS doesn't? I haven't researched a lot |
| 00:05 |
MTDiscord |
<greenxenith> We should just be providing as much info as reasonably feasible |
| 00:06 |
MTDiscord |
<mark.wiemer> Yes, I think we're all on the same page there. That will definitely be my focus |
| 00:06 |
MTDiscord |
<mark.wiemer> We can add features to language servers if needed once we have the data π |
| 00:12 |
MTDiscord |
<a.corp.serot> personally, i'm hoping a really detailed spec down to what number types/ranges are valid, typing ids (e.g. node ids are a subtype of strings), complete defined defaults (opposed to current undefined defaults), making distinctions on runtime vs startup vs on_mods_loaded vs async env vs mapgen env, making distinctions on engine's prefilled outputs vs inputs (e.g. getting sky parameters are prefilled with default values meaning you |
| 00:12 |
MTDiscord |
don't need to check. compare with setting sky parameters where all properties are optional) |
| 00:20 |
MTDiscord |
<mark.wiemer> Examples would be great π in case you don't know me I helped with docs.luanti.org but in terms of actual experience I'd never written Lua before, and I've barely made Hello World in Luanti. But I'm a professional software engineer so I know what I'm talking about in the more general sense I promise! |
| 00:24 |
MTDiscord |
<a.corp.serot> number types would be integer and/or floats. most of luanti API can use both. but some have restrictions on integer size (i.e. u8 or i16) or specifically need integers (i.e. position hashing and voxelmanip/list indexing through API instead of table[i]) or has restrictions on acceptable ranges (i.e. light being between 0..LIGHT_MAX which is 0..14) |
| 00:24 |
MTDiscord |
<mark.wiemer> I am thinking even more concrete, like share a snippet of the current docs and a snippet of how you'd like the docs to look, including the additional info you're thinking of |
| 00:25 |
MTDiscord |
<mark.wiemer> Just so I can get a better feel of how you're thinking |
| 00:31 |
MTDiscord |
<mark.wiemer> Even better, comment in https://github.com/luanti-org/docs.luanti.org/issues/296 so your messages don't float away π |
| 00:37 |
MTDiscord |
<a.corp.serot> i'll put out a gist explaining each of those in the issue. it's a bit long to explain as a single comment :) |
| 01:51 |
MTDiscord |
<mark.wiemer> I do think I'll be focusing on core namespace reference for a while, it's 2300 lines and seems easy to clean up (just make sure function arg types, return types, and sample code is provided for each func). Seems to have the best ROI for a start in the project, at least. If you think there are better starting sections for a schema, I'm all ears! Here is the current breakdown by top-level headers: |
| 01:51 |
MTDiscord |
<mark.wiemer> https://cdn.discordapp.com/attachments/926231483155378176/1444868488987541624/image.png?ex=692e4624&is=692cf4a4&hm=cba474a3c9f0899e4e067d3a027f0f23c8ecf906690acfbb1514feddb9d11e97& |
| 01:52 |
MTDiscord |
<mark.wiemer> (for when the image is inevitably deleted, it's just https://github.com/luanti-org/luanti/blob/d30113a70a8464cb88ddc7e832d9a37ecf6ad063/doc/lua_api.md, collapse all sections, review line numbers) |
| 05:00 |
|
MTDiscord joined #luanti-docs |
| 05:40 |
MTDiscord |
<a.corp.serot> i've made a gist explaining it, it's in the linked issue. although i'm pretty sure it's possible to encode all of the desired information in the form of the markdown spec, it's probably going to need a lot of human work. as in, you can't parse lua_api.md into giving the desired info |
| 15:53 |
|
Desour joined #luanti-docs |
| 18:29 |
MTDiscord |
<mark.wiemer> The goal is to update lua_api.md significantly so that we can parse it. Consistent format, more info. Β The devil is in the details. I'll review the gist when I have time, but I'm extremely busy this week it turns out π |
| 19:11 |
|
mrcheese joined #luanti-docs |
| 21:59 |
|
mrcheese joined #luanti-docs |
