[01:30:39] legoktm: I vaguely recall you doing something with User:/apioutput.css/js at some point. Is that true? Might be of interset: https://phabricator.wikimedia.org/T297779 [02:06:23] Krinkle: I merged that into https://phabricator.wikimedia.org/T132720 where we previously discussed this :) [03:16:40] legoktm: my proposal there was terrible [03:16:48] disable common.js only? [03:17:20] that's likely its own cause of errors :D [03:17:27] thx for digging it up [12:46:02] duesen: Krinkle any name suggestion for title_title column of title table? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/754989 [12:46:22] I have two title_value and title_text but none are that better than title_title [13:19:41] Amir1: problem with text is that it's db form not text form [13:21:55] yeah it's not optimal but I can't think of a better name [14:31:40] Amir1: so.. apart from the famous title class, a common word for this is page name. In wikitext magic words and in mw config the full thing is a page name, made of a title and namespace. [14:31:57] So maybe pagename and pn_title,ns [14:33:36] Or even page_title and page_namespace as-is if we want to sacrifice naming scheme for continuity and familiarity [14:33:47] Krinkle: the thing is that this can not be a page or related to a page given that it's going to hold templatelinks, etc. and those don't move and are immutable (unlike page) [14:33:56] We've done that in numerous tables already [14:34:02] I want to avoid issues like that in the future [14:35:47] Amir1: you mean it might not yet exist or be special /not editable. Or something that isn't a local wiki page at all, like interwiki? [14:36:54] no, I mean these are bound to the wikitext of the page, e.g. {{Foo}} must have Foo, if Template:Foo moves without redirect, the title here should not change [14:37:36] Sure [14:38:04] But are you saying we will not use this for the page table as well one day? [14:38:41] I assumed we would eg have page.pagename_id at some point as well [14:39:31] Unique/Append only same as actor and use there when updating [14:39:45] I don't think we will use this for pages [14:40:22] it doesn't give much benefit normalizing this, page table is not large (and there is no repetition) [14:40:29] Okay [14:40:57] Well then calling it title might be a bit too generic [14:41:08] but you need to add join which can get costly, not to mention god knows ho many places need to change [14:41:13] linktarget.lt_title,namespace [14:41:32] hmm [14:41:42] that sounds good [14:43:55] do we have a class called LinkTarget [14:43:58] I think we do [14:44:07] It's an interface for TitleValue [14:45:42] Wikitext links are represented by LinkTarget, rendered by LinkRenderer, stored in link tables by LinksUpdate. [14:46:01] The consistency is astonishing [14:46:52] that's rare [14:47:01] so lt_title? lt_text? [14:53:21] went with lt_title :D [15:00:04] Yeah, text is display form instead of db key form [15:03:32] <_joe_> given I was asking yesterday: i managed to make vscodium use phpcs for the linter / use phpcbf as a formatter https://phabricator.wikimedia.org/P18972 [15:03:57] <_joe_> I don't have to count my whitespaces anymore :P [15:11:38] <_joe_> more in general, I was wondering if there is a canonical place for writing down suggestions for configuring editors for mw development [15:41:02] I use Sublime Text with basically no plugins other than plugins for navigation and highlighting. no linters or formatters. If the coding style isn't native yet, then an ESLint plugin or a plugin for phpcs would certainly help to give you little red squiggles as you type to get the coding style right. ESLint plugins are widely available easy to run standalone. I haven't found a simple plugin for phpcs to that end, but also haven't looked [15:41:02] for it as our php style is the one I know best/longest. [15:42:09] (plus eslint is more than a linter, it tells you a lot of static analysis as well, and it evolves a fair bit to make things stricter over time.) [16:02:55] _joe_: I don't know if there is such a place yet, but if there was I would personally start looking for it from https://www.mediawiki.org/wiki/Manual:Coding_conventions [16:04:00] I see some stuff at the top of https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP about https://stylize.toolforge.org/ which is cute but editor integrations would be more ideal surely [16:05:39] <_joe_> bd808: yeah I'm now running phpcbf at save time [16:05:44] <_joe_> it's making my life much easier [16:06:12] _joe_: you use/made a wrapper that focusses on changed files? [16:06:21] for js - https://www.mediawiki.org/wiki/Manual:Coding_conventions/JavaScript#Linting [16:06:26] <_joe_> Krinkle: I have format on save [16:06:37] <_joe_> so when I save a file, that gets linted/fixed [16:06:45] _joe_: *nod* black is my friend for similar reasons :) [16:07:06] <_joe_> the reason it's so difficult for me is that the spacing in mediawiki's code conventions is... unconventional [16:07:28] <_joe_> so given I write small patches occasionally I don't want to have to use the muscle memory to remember how it should work [16:07:36] <_joe_> also, go with gofmt really spoiled me [16:07:45] yeah, I'd love to have a long talk with whomever felt that so much horizontal whitespace was ideal [16:07:49] <_joe_> go has *one* way to format code, for eveyr repository on earth [16:08:07] gofmt is probably the most brilliant thing about that language [16:08:49] <_joe_> uhm I disagree [16:08:53] <_joe_> goroutines are [16:09:16] <_joe_> goroutines/channels/etc [16:09:59] my go hacking experience is one toy project and 3-4 patches to blubber so... [16:10:48] <_joe_> but yeah, the fundamental thing that was realized with gofmt is that code's best quality is future readability