| Time |
Nick |
Message |
| 03:18 |
MTDiscord |
<theidealist> I've no idea what frobnication is but it sounds epic |
| 04:00 |
|
MTDiscord joined #luanti-docs |
| 08:46 |
|
Warr1024 joined #luanti-docs |
| 14:08 |
MTDiscord |
<warr1024> Not spellchecking code is how you end up with an API to send people conformation emails after they complete regitsration. Just use a decent one that knows about jargon and doesn't try to enforce linguistic lacunas. |
| 14:20 |
MTDiscord |
<luatic> Not spellchecking code in a documentation repo is probably fine, and I'm doubtful of how aware a decent spellchecker can be of all the common abbreviations used in programming. The one we're currently using clearly isn't. |
| 14:38 |
MTDiscord |
<warr1024> The rules for what should be allowed in code comments are exactly the same as what's allowed in ordinary documentation. The only thing you'd have to worry about is the code itself. A context-aware spellchecker would be nice, but ultimately code generally only has so many keywords, and quite a lot of them are already in the dictionary. |
| 14:39 |
MTDiscord |
<warr1024> Do you have any examples of problems specific to code? The ones you described before are already wrong and it has nothing to do with code, it was only coincidence that you happened to find them in code to begin with. |
| 14:44 |
MTDiscord |
<luatic> Agreed on the code comments, but we don't really have much of a need for comments I think, because most stuff can and should be in prose. An ideal spellchecker should just run a tokenizer per-language to check them too, but it's good enough to outright ignore code I think. |
| 14:46 |
MTDiscord |
<luatic> Yes, plenty of examples are in cspell.json: containsi, containsp, cracko, difftime, dofile, dtime, errfunc, the list goes on and on |
| 14:52 |
MTDiscord |
<warr1024> Ah, that's "C culture" I suppose. Maybe spelling as a concept just doesn't really exist. It works a lot better for codebases where you've got identifiers like HasSentConfirmationEmail and stuff. |
| 14:53 |
MTDiscord |
<warr1024> The need for code comments in code that's embedded in documentation mostly just depends on length, and whether, for the longer sections, you're okay breaking back out of the code block to comment, or whether you want to keep everything in a single longer pasteable code block. Or whether you even allow long code sections, potentially mooting the issue. |
| 15:12 |
MTDiscord |
<fyl2xp1> TBF C abbreviations are usually a lot worse. But I agree that typing a few extra letters to make an identifier less guesswork is almost always preferable. But in that context I think that the code examples should follow the original code for now, until the original is fixed™. (disclaimer: I didn't look up the specific code locations that are being discussed here) |
| 15:14 |
MTDiscord |
<warr1024> There are a lot of different strategies for making identifiers more understandable: comments and other built-in documentation methods; longer explicit names; minimizing scope; etc. The preferred method for C codebases seems to be (checks notes) none of them. |
| 15:14 |
MTDiscord |
<luatic> many of these are things where we have no choice, because that's simply what the identifier is called |
| 15:15 |
MTDiscord |
<luatic> contains(i|p) are voxelarea methods, cracko is a texture modifier, os.difftime is a lua stdlib function, as is dofile. dtime could arguably be given another name but i think it's fine. same for errfunc. |
| 15:21 |
MTDiscord |
<warr1024> dofile and difftime aren't even misspellings, they're neologisms 😏 |
| 15:41 |
MTDiscord |
<josiah_wi> https://www.gnu.org/software/libc/manual/2.22/html_node/strfry.html |
| 16:06 |
MTDiscord |
<luatic> sounds like it isn't even a fisher-yates but rather a broken shuffle? 😭 |
| 17:31 |
|
Desour joined #luanti-docs |
| 20:44 |
|
GreenXenith joined #luanti-docs |
| 21:10 |
|
MTDiscord joined #luanti-docs |
