Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Nao
6946
Features / Re: Fixing mismatched BBCode
« on December 6th, 2011, 08:24 AM »
AND.... Interestingly, the same code can be reused for proper quote de-nesting :)
6947
Features / Re: Privacy options
« on December 5th, 2011, 10:04 PM »
Good idea though: sending pms to a contact list :P
6948
Features / Re: Fixing mismatched BBCode
« on December 5th, 2011, 08:12 PM »
I'm guessing that if you're gonna use the code tag inside another, you'll want to add a matching closer, and since this one'll break the whole block, you'll add a space somewhere to break the closer instead... So might as well wanna break the opener as well with a space. Anyway...
Here's the code, for those interested. It seems to work, at least on my test cases. Maybe you can figure out a faster/shorter way to do it ;)
Code: [Select]
(Of course, the irony is that I had to add a space to the tags... :whistle:)
Here's the code, for those interested. It seems to work, at least on my test cases. Maybe you can figure out a faster/shorter way to do it ;)
// Find all code blocks, and ensure they follow the [ code][ /code] syntax closely.
if (preg_match_all('~\[(/?)code[^]]*]~i', $message, $matches))
{
$pos = 0;
$tags = array();
foreach ($matches[0] as $id => $tag)
{
$tag_pos = strpos($message, $tag, $pos);
$length = strlen($tag);
$tags[] = array($tag_pos, $length, $matches[1][$id] === '/');
$pos = $tag_pos + $length;
}
$was_closed = true;
$offset = 0;
foreach ($tags as $tag)
{
if ($was_closed === $tag[2]) // consecutive closing tags, or closing tag at the beginning?
{
$message = substr($message, 0, $tag[0] + $offset) . substr($message, $tag[0] + $tag[1] + $offset);
$offset -= $tag[1];
}
$was_closed = $tag[2];
}
if (!$tag[2]) // no final closing tag?
$message .= '[ /code]';
}(Of course, the irony is that I had to add a space to the tags... :whistle:)
6949
Features / Re: Fixing mismatched BBCode
« on December 5th, 2011, 07:21 PM »
My new rewrite is a bit messy and longer. What do you think about this: I'm parsing the message to remove any misplaced code tags. Eg two opening tags? The second one is removed. Same for closing tags. Etc. Not in my pc so I won't elaborate. This of course makes it impossible to type in a code tag inside another but who cares.
6950
Features / Re: Post moderation
« on December 5th, 2011, 07:19 PM »
Performance isn't an issue. It's only called at post time right?
6951
Features / Re: Fixing mismatched BBCode
« on December 5th, 2011, 11:48 AM »
But that would mean a fuller rewrite of preparsecode, which I'm not ready/willing to do... ;)
So, I'm looking at the code tag stuff and all I see is that it's mainly used to deal with special tags only when they're outside code tags. It'd be more solid to actually search for [ code] from the current offset, make a string out of it, deal with it, then search for the next [ /code] (if not found, add [ /code] at the end of the post), set it as the new offset, and loop.
PS: long PMs eh...! Will answer later today.
So, I'm looking at the code tag stuff and all I see is that it's mainly used to deal with special tags only when they're outside code tags. It'd be more solid to actually search for [ code] from the current offset, make a string out of it, deal with it, then search for the next [ /code] (if not found, add [ /code] at the end of the post), set it as the new offset, and loop.
PS: long PMs eh...! Will answer later today.
6952
Features / Re: Fixing mismatched BBCode
« on December 5th, 2011, 10:27 AM »
I'm actually considering rewriting the splitter to use the strpos (with offset) technique I used a few months ago... It's probably going to be faster, and more solid.
6953
Features / Re: Fixing mismatched BBCode
« on December 5th, 2011, 07:21 AM »
Search for $in_tag in class-editor?
6954
Features / Re: Fixing mismatched BBCode
« on December 5th, 2011, 12:38 AM »
So, do you mean that the code I posted above would be 'perfect' for Wedge?
6955
Features / Re: Fixing mismatched BBCode
« on December 4th, 2011, 11:44 PM »
So... How about we forget about closers, and only deal with fixing openers?
6956
Features / Re: New revs
« on December 4th, 2011, 11:42 PM »
rev 1185
(6 files, 9kb) -- my work for the weekend... Good luck trying to understand any of it.
+ Added support for ISO to UTF8 conversions in the westr class. New functions: is_utf8(), force_utf8() and to_utf8(). New variables: $can_utf and $can_iconv. Made $can_* variables public because it's mostly harmless. (Class-String.php)
! The westr class wasn't being initialized at all, thus Subs-Charset was never loaded, and self::$can_mb wasn't set. (Load.php)
- There's no need to specify 'public' in front of public methods. It may be clearer, but it also takes space for nothing. (Class-String.php)
* Benchmarked these regex variations in westr and it turned out that the longer ones were faster... Uh. (Class-String.php)
* Scarcely used westr::safe() now is the equivalent of westr::htmlspecialchars, only the $force_utf8 and $double_enc param defaults are reversed. (Class-String.php)
! Fixed Aeva Media throwing out an 'empty post' error when all of these conditions were set: PHP < 5.4, title lookups enabled, and title had an entity that was decoded to an unsafe character (i.e. something that doesn't convert to the same byte sequence in UTF-8 and ISO-8859-1). Also fixed an unrelated call in the BBC parser that uses the same function. (Aeva-Embed.php, Subs-BBC.php)
* A few necessary rewrites for subject and post sanitation (sanitizing?), used the opportunity to be bitchy and play with fire by forcing ENT_NOQUOTES on the htmlspecialchars calls... Let's see how it goes. (Post2.php)
* Various & fixes. Don't ask, it's complicated. (ManageBoards.php)
(6 files, 9kb) -- my work for the weekend... Good luck trying to understand any of it.
+ Added support for ISO to UTF8 conversions in the westr class. New functions: is_utf8(), force_utf8() and to_utf8(). New variables: $can_utf and $can_iconv. Made $can_* variables public because it's mostly harmless. (Class-String.php)
! The westr class wasn't being initialized at all, thus Subs-Charset was never loaded, and self::$can_mb wasn't set. (Load.php)
- There's no need to specify 'public' in front of public methods. It may be clearer, but it also takes space for nothing. (Class-String.php)
* Benchmarked these regex variations in westr and it turned out that the longer ones were faster... Uh. (Class-String.php)
* Scarcely used westr::safe() now is the equivalent of westr::htmlspecialchars, only the $force_utf8 and $double_enc param defaults are reversed. (Class-String.php)
! Fixed Aeva Media throwing out an 'empty post' error when all of these conditions were set: PHP < 5.4, title lookups enabled, and title had an entity that was decoded to an unsafe character (i.e. something that doesn't convert to the same byte sequence in UTF-8 and ISO-8859-1). Also fixed an unrelated call in the BBC parser that uses the same function. (Aeva-Embed.php, Subs-BBC.php)
* A few necessary rewrites for subject and post sanitation (sanitizing?), used the opportunity to be bitchy and play with fire by forcing ENT_NOQUOTES on the htmlspecialchars calls... Let's see how it goes. (Post2.php)
* Various & fixes. Don't ask, it's complicated. (ManageBoards.php)
6957
Features / Re: Fixing mismatched BBCode
« on December 4th, 2011, 11:13 PM »
Yeah, it's all a bit complicated... If in SMF you type /code then code, it will simply add the closing code at the end, and leave the first /code as is.
Here's my original rewrite:
Code: [Select]
I think it's quite elegant, but it has the problems I mentioned above.
Now... Why exactly is it so important to have matching tags? AFAIK, because the parser doesn't do recursive regex magic, it doesn't really care whether there are mismatched tags. In fact, it's even worthless to add a code tag before the post is there's an extra /code overall: because the /code is probably a mistake on the user's part, and I'm sure they'd rather see an untransformed post, rather than everything turned to a large code block for no reason whatsoever (in their opinion)...
So, technically, there is not even a strong reason to have the last 3 lines in the code above. It won't change a thing...
Heck, could probably even get rid of it all... :-/
Here's my original rewrite:
if (preg_match_all('~\[(/)?code[^]]*\]~i', $message, $matches))
foreach ($matches[1] as $tag)
$num_tags += (empty($tag) ? 1 : -1);
// If we have open tags, close them.
while ($num_tags > 0 && $num_tags--)
$message .= '[/ code]';
// Open any ones that need to be open, only if we've never had a tag.
while ($num_tags < 0 && $num_tags++)
$message = '[code]' . $message;I think it's quite elegant, but it has the problems I mentioned above.
Now... Why exactly is it so important to have matching tags? AFAIK, because the parser doesn't do recursive regex magic, it doesn't really care whether there are mismatched tags. In fact, it's even worthless to add a code tag before the post is there's an extra /code overall: because the /code is probably a mistake on the user's part, and I'm sure they'd rather see an untransformed post, rather than everything turned to a large code block for no reason whatsoever (in their opinion)...
So, technically, there is not even a strong reason to have the last 3 lines in the code above. It won't change a thing...
Heck, could probably even get rid of it all... :-/
6958
Features / Fixing mismatched BBCode
« on December 4th, 2011, 11:59 AM »
The code in Class-Editor that straightens out missing code tags is quite odd to look at... Some variables are initialized and never actually used, etc. I looked into it and decided to rewrite it. As a result, I did pretty much the same thing -- in only three lines of code instead of 10.
Now, the thing is that the I'm using a $num_tags variable instead, which is incremented or decremented based on whether it meets an opening or closing tag. Although technically it works (if you have two opened code tags, it will addd two closers), in reality it doesn't work as expected. Two examples:
- if you first use a closer, then an opener, $num_tags will be set to zero and nothing will be fixed. The code needs to be smarter than that.
- if you use two openers and a closer, Wedge will add an extra closer... Except that code tags within other code tags are treated as code (not tags), so they don't need a closer. It's always been a mess in SMF because if you add two closer tags here, the second one is shown as plain text, instead of the first one. Here, I'd tend to say this is a SMF bug that needs to be fixed in Wedge... What do you think?
Now, the thing is that the I'm using a $num_tags variable instead, which is incremented or decremented based on whether it meets an opening or closing tag. Although technically it works (if you have two opened code tags, it will addd two closers), in reality it doesn't work as expected. Two examples:
- if you first use a closer, then an opener, $num_tags will be set to zero and nothing will be fixed. The code needs to be smarter than that.
- if you use two openers and a closer, Wedge will add an extra closer... Except that code tags within other code tags are treated as code (not tags), so they don't need a closer. It's always been a mess in SMF because if you add two closer tags here, the second one is shown as plain text, instead of the first one. Here, I'd tend to say this is a SMF bug that needs to be fixed in Wedge... What do you think?
6959
Features / Re: Privacy options
« on December 4th, 2011, 11:51 AM »
It's not exactly the same -- a draft is stored in a special area of your profile, while a 'privacy' draft is stored inside your forum/blog and you can access it easily until the moment you decide to make it public.
Would that be disorientig...?
Regarding the poll, it would seem that:
- a third of our users don't care about topic privacy settings,
- the rest does,
- everyone but you seems to be interested in multiple contact lists, rather than a single contact list.
I'm not sure I can make a decision based on a relatively small sample of users (11 people, 9 not including us.)
It's not like it's a piece of cake to implement this... Although it's not going to be a disaster, either :P
Oh, and regarding your post-moderation UI issues - how about you set it aside and come back to it in a month or two?
Would that be disorientig...?
Regarding the poll, it would seem that:
- a third of our users don't care about topic privacy settings,
- the rest does,
- everyone but you seems to be interested in multiple contact lists, rather than a single contact list.
I'm not sure I can make a decision based on a relatively small sample of users (11 people, 9 not including us.)
It's not like it's a piece of cake to implement this... Although it's not going to be a disaster, either :P
Oh, and regarding your post-moderation UI issues - how about you set it aside and come back to it in a month or two?
6960
Features / Re: New revs
« on December 2nd, 2011, 07:45 PM »
rev 1184
(3 files, 7kb)
! Thoughts should be pre-parsed before saving. (Ajax.php)
* The homepage thought code wasn't using the MVC model... Ouch. (Welcome.php, Welcome.template.php)
(3 files, 7kb)
! Thoughts should be pre-parsed before saving. (Ajax.php)
* The homepage thought code wasn't using the MVC model... Ouch. (Welcome.php, Welcome.template.php)