in main page [18:42:28] ah [18:42:36] Didn't track it down, but saw enough in Firebug to know that was it, and had to go [18:43:25] So the regex I used instead was (\s)*\[\[(([^|]+)\|)?([^]]+)\]\](\s*) [18:43:55] Or in more readable terms (whitespace*)[[(stuff+\|)?(stuff+)]](whitespace+) [18:44:08] Ah [18:44:13] ((stuff+)|)? [18:44:34] So the idea is you can put parenthesized expressions in an optional part [18:44:44] And they'll just be null if the optional part isn't matched, AFAIK [18:45:07] hmm [18:45:25] So in this case there was interesting data in the optional part [18:45:26] so rather than or them together, you make a series of optional parenthesized expressions [18:45:30] But you can use this even if there's not [18:45:49] By parenthesizing an optional part (almost always doing this if the optional part is complex), then querying it [18:46:14] Caring just about null/not null and ignoring its actual value (which will be a constant anyway) [18:47:22] TrevorParscal: What's this bias thing in your code about? [18:47:51] is the important part of the match on the left or right [18:48:14] So it's 0 or 1? [18:48:27] yes, you take index + ( offset * bias ) to get the boundary [18:48:40] and it's -1 or 1 [18:49:09] it's much more flexible [18:49:16] Where index and offset are what exactly? [18:50:12] index is the left side of the match [18:50:35] offset is the distance to the effective boundary, bias is the direction [18:50:51] 'effective boundary'? [18:51:07] yeah, the left side if }} is not the interesting part [18:51:10] the right side is [18:51:17] we store the offset in a signed form [18:51:24] so there's the left side [18:51:37] and the offset might take it over to the right [18:52:01] OK so in practical terms [18:52:08] Say I have {{foo}} and don't care about the braces [18:52:18] What would index, offset and bias be respectively? [18:52:45] well that's two tokens [18:52:50] and opening token and a closing one [18:53:08] Right [18:53:47] So index=0 , offset=2 for the opening {{ ? [18:53:57] yeah [18:54:23] ok [18:54:28] this is a bit mixed up i think [18:54:32] what you are noticing.. [18:54:48] now I'm confused... [18:54:58] this is why this is not exactly done :) [18:55:16] I'm trying to be convinced that I'm wrong about my s/-1/0/ thought [18:56:03] the bias comes from what would otherwise be the "mark after" flag [18:56:23] but this is a mixed up function [18:56:35] I have a function that works right, in my mediawiki parser 2.0 [18:56:43] Yes I got that [18:56:45] and I started applying that [18:56:51] but it's not quite right yet [18:56:52] sorry [18:56:54] But intuitively I'm thinking it should be 0 and 1, not -1 and 1 [18:56:58] Oh BTW [18:57:00] ? [18:57:02] About that new parser of yours [18:57:04] yeah [18:57:11] I was talking to a friend of mine from uni the other day [18:57:16] k [18:57:40] And his suggestion to make WP easier to edit was sentence-level in-place editing, he had some interesting ideas about the technical realization about that [18:57:54] They sounded feasible, at least relative to the task [18:58:14] I brought up a dozen issues he didn't know about (to be expected) but none of those seemed insurmountable [18:59:15] Sentence level would be 1 level of granularity (for paragraphs only) above my block level approach [18:59:27] which is neat [18:59:28] Yes [18:59:35] I immediately brought up your block-level approach [18:59:41] But it's a more hacky solution, not requiring a new parser [18:59:48] Basically what it does is this [19:00:05] Well, there's a couple issues, 1 sentences are faster moving targets than blocks [19:00:13] It examines the parser's HTML output and identifies editable sentences, where it's quite lazy about the definition of editable [19:00:27] 2 the problems with wikitext parsing arent paragraphs, they are everyhing else [19:00:30] Links are OK but anything beyond that is too complex [19:00:38] sentence level identification doesnt fix that stuff [19:00:44] Or maybe it examines wikitext, that's possible [19:00:46] I know [19:00:58] But it would allow quick correction of typos and such [19:01:06] but, within paragraphs, being able to identify a sentence would be neat [19:01:07] With neat AJAX stuff [19:01:10] right [19:01:15] much less data being passed around [19:01:22] the moving target thing get crazy though [19:01:26] you need federation [19:01:31] i gtg get some food [19:01:34] bb in a min [19:01:39] So basically his proposed approach is to identify and span-wrap easily editable sentences [19:02:02] Then, when you click Quick Edit, all editable sentences would be highlighted and you can click on one to turn it into a textbox [19:36:59] TrevorParscal: you around? [19:37:58] he's eating lunch. [19:38:20] i am back [19:38:23] what's up? [19:38:30] adam_miller: :) [19:39:16] yo, i noticed that the label on simplesearch is being added with JS [19:39:23] so no JS, no label [19:39:28] why do we do it that way? [19:40:13] well, we need js to automatically hide it [19:40:35] so, if it were present with or without js, then there would be cases where it would never get hidden [19:41:42] why not just keep it beside the text box by default and add some css rules with JS [19:41:45] ? [19:42:17] we could [19:42:24] is there a benefit to doing that? [19:42:31] I don't see the problem with it... [19:42:43] allthough, I will say [19:42:44] well if you don't have a problem denying users w/o JS the label [19:42:52] when you look at the page without any css [19:43:02] there's already an H5 that we hide that says "Search" [19:43:26] so, if you include the label in the markup, it will say "Search Search [ -- box -- ]" [19:44:05] I wish there was a css rule for :empty [19:44:09] or something.. [19:44:23] anyways [19:44:30] well i dont know, it was just one of those things which you did differently than I would have [19:44:44] it's probably fine as is, just wanted to understand your reasoning so I could explain it to people [19:44:51] for sure [19:45:11] other than the view without style thing, I don't see any problem with including the label in the original markup [19:46:22] probably a pretty low priority task though for now [19:46:54] i'm working on getting the label and magnifying glass icon positioned consistently...i think that's more important [19:47:24] yes, that seems to be tricky between browsers, at least the way I laid it out.. [19:47:30] which could likely be change/improved [20:04:04] Hm [20:04:32] If user opt-in into Beta and then change skin back to monobook, does he count as opted out? [20:34:05] we track opting in and out, and then apply that to changing preferences back when we change defaults [20:34:08] so, it shouls [20:34:12] *should [20:34:23] if it did not, please let us know, and we are sorry about that.. [20:35:21] TrevorParscal: does it work though if they manually switch the skin back (instead of clicking the optout button)? I think that may have been the question [20:36:00] it should, we do not log based on which button is clicked, we log based on the preference being changed [20:36:05] however it's done [20:36:17] except by someone manually editing the database record of course... [20:36:52] TrevorParscal, roan removed you from bug 23490 when assigning to him, he probably forgot to CC you [20:36:57] in case you're interested in that bug [20:37:48] ah ok [20:37:49] awesome [20:49:57] Platonides: i'm on it now [20:55:50] by the way, does the makefile work now for you? [20:58:11] yes [20:58:47] no [20:59:02] it creates UsabilityInitiaive.hooks.php-e [20:59:52] and the lack of documentation is a big problem [21:00:15] but, it's cool that you are poking at this [21:00:19] *jorm is about to explode. [21:00:21] it's something we kept putting off [21:00:37] is there a reason why apache might not be paying attention to /etc/php.ini ? [21:01:02] php reads that, not apache [21:01:08] afaik [21:01:20] "UsabilityInitiaive.hooks.php.php-e" ? [21:01:23] well, yeah, but on startup of the module, is my understanding. [21:01:42] that's quite odd [21:01:44] i'm getting a bunch of errors about default timezone, and i'm setting it in php.ini, and it's not reading. [21:02:22] jorm, create a phpinfo() and look the expected php.ini [21:02:49] Platonides: if you document the desired behavior better (or at all) someone else can step in and fix it up on their platform [21:03:38] good idea. [21:06:15] nice. /usr/local/lib [21:10:16] I added some explanation on r67867. [21:11:42] thanks [21:49:58] TrevorParscal: where do i bump the revision when I change the main vector stylesheet? [21:50:04] it's been so long.... [21:50:22] includes/DefaultsSettings.php [21:50:29] look for $wgStyleVersion [21:56:52] TrevorParscal: should these simple search styles be in main-ltr.css? [21:57:04] shouldn't there be a wikiEditor.simpleSearch.css file or something? [21:57:11] Platonides: is it possible to run the makefile without the bumping by passing an arugment, just in the case that it's failing on a plarform? [21:57:35] there's 2 things called simple search [21:57:39] the markup only version [21:57:54] and the jquery plugin [21:59:03] too much work to come up with a different name for the jquery portion? [21:59:41] TrevorParscal, you could make the target [21:59:56] although you would need to know what is it [21:59:56] also, how can i disable the jquery portion to ensure what i'm doing is fixing alignment for both cases and not just when you have both enabled? [22:00:06] most probably the corresponding .min.js [22:00:54] just change your LocalSettings.php file [22:01:14] there's a request to add a setting the prefs page for it [22:04:56] TrevorParscal: what happened to the makefile? it got all fancy on me all of a sudden? [22:05:24] yeah, Platonides has been poking at it [22:05:27] did it work for you? [22:05:36] it's supposed to auto-incriment the version numbers [22:05:37] last night it did some weird things [22:05:41] i'm gonna trust it this time [22:05:44] but it's been failing on me [22:05:57] maybe i'll just take a look at what it did before committing [22:06:21] it's always a good idea :) [22:06:28] where are you running it? [22:07:07] not sure what you mean exactly....from the root of the UsabilityInitiaive extension [22:07:46] Platonides: what are the *.php-e files it creates? [22:07:46] which enviroment, what OS? [22:07:47] on OSX right? [22:07:53] 10.6.2 [22:07:57] bash [22:08:02] adam_miller, it shouldn't be creating php-e files :( [22:08:04] adam_miller: that's not on purpose [22:08:14] damn [22:08:29] it's taking -i -e as use "-e as a suffix" [22:08:45] ..... [22:08:52] i messed with -ie it still messed up [22:09:00] does it work if you move -i to the end of the command line? [22:09:10] well i can just commit this and delete them [22:09:13] then it just does nothing [22:09:14] NBD [22:09:24] adam_miller: I'm not sure... [22:09:43] to be safe, you need to update the makefile to it's previous version and run it [22:09:51] oh [22:09:52] adam_miller, you can, but you will need to manually update the file [22:09:57] like it's screwing up the combined files? [22:10:03] the diff looks good [22:10:05] no [22:10:10] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/67743 [22:10:20] it will be saving it changes to the php-e instead of its same file [22:10:35] it didnt for me [22:10:54] it bumped the version numbers in the files which are being tracked [22:11:05] then it worked [22:11:06] i didn't bother to look in the php-e files [22:11:27] so why does it create php-e files? :s [22:11:54] Platonides: you don't have OSX, but if you have BSD handy it should behave the same [22:12:08] not handy [22:12:20] but I could try to install it on a VM [22:12:22] i didn't expect you would :) [22:12:29] you are a trooper [22:12:42] xD [22:15:18] brb