Wedge

Back on 2003 I used Spip.net and it had a much better presentation code system. { for italics, {{ for bold, it had code for footnotes too and intertitles. I missed footnotes, hence why they're in Wedge.
http://dossiers.cyna.fr was built with Spip.

I tend to use html tables on a wiki. I like the html passthrough.
I'm not sure, either, how wikitable syntax is easier than HTML.
Either wikitable or HTML beats BBcode for tables. No styling, no padding, no margins = ugly BBcode tables.

Let me clarify one thing right now.

The lack of styling, padding and margins is not a flaw of bbcode as a whole. It's a limitation *solely imposed in SMF* through one of the more... irritating 'features' it has, one of which I will be happy to note is the source of a bug that's *years* old and still not fixed because no-one wants to do the work required to fix it, which is more than a few lines of tweaking but gutting the bbcode preparser and rebuilding it.[1]

The other thing about using the html passthrough is the inherent insecurity of doing so...

As far as wikitable syntax, I'm assuming we're both thinking of the same thing, using | and - and { and } to indicate structure *shudder*.

1.

Specifically, while there is, on the surface, nothing preventing adding such attributes to the table bbcode, the way certain common structures are validated will specifically break doing so, because it will assume that it's invalid markup simply because it's not a basic table tag containing a basic tr tag. It's a flaw of a specific implementation, not of the overall concept.

Starting starting over from scratch with parse_bbc might be in order.
The current design requirements for a replacement would be a bit different from the original design requirements. Times have changed.

Not only "better formatting" but also ways to use a limited bbcode set in an embedded AJAX thingy (chat or other thingy) without affecting the bbcode set available for rendering the main content of the page. etc.
Not to mention -- optimization. [Unknown] said he had to reject regexp in parse_bbc, because he realized that, though it would normally be faster, there could be some "weird posts" that would take ridiculously long to parse using a regexp-based parser.

There is already a shortened version of parse_bbc for such inline purposes, as it happens.

As for the rejection of regexp, yup such things are called ReDoS situations where a badly crafted post could tie the parser up, denying service to others. I actually don't dislike what Unknown has done in the original parse_bbc actually, I just wish it were faster, but the real problem isn't the parser, but the pre parser, which I think is ultimately going to have to be rewritten.

I've proven recently that a series of strpos calls could actually be faster than even a well crafted regex. The regex is still available for comparison in a comment.

That reminds me. Pete, could you deal with adding the prepare code to thoughts? It shouldn't be too annoying as they're only treated in Ajax.php. Or just remind me when I'm on my pc.

Added it myself...
Just one thing to note.
Before wedit::preparsecode, used in various places around Wedge, there's always an htmlspecialchars() call.
Well, while I'm wary of this kind of thing being done (because maybe it should be done inside preparsecode itself if we're going to make life easier for modders...), I did notice an intriguing detail: sometimes it's called without arguments, and sometimes it's called with ENT_QUOTES.
I have a feeling this is something that is due to different devs doing the code at different points in time, and maybe we should harmonize everything. Shouldn't we...? I'd suggest removing all ENT_QUOTES and maybe even push for ENT_NOQUOTES... Because I can't think of a reason to protect parsed BBC against quotes.

Also -- maybe add the double_encode param while we're at it?

Hmm. Such a thing is not simple because the preparse step is called in different ways at different times (like it's called inside sendpm as opposed to sendpm expecting it to be already done like createPost does)

The times it's called with ENT_QUOTES is where it expects to see a ' and/or a " to deal with. In posts, that is a valid situation to deal with, especially since it can manifest itself in a slightly disturbing way, notably that not doing it might potentially lead to a vulnerability. I'm not sufficiently comfortable with turning it into NOQUOTES for that reason.

Harmonisation, yes. Probably even moving it all into preparsecode, but with the caveat that it will require more than just moving a few calls, as sendpm will need updating.

Where is demo?

I'm sorry, I missed the part where 'target' became 'irreversible deadline'. Probably all the personal crap I had going on made me miss that memo.

There is a demo. It isn't public, but invitation only at this time.

Chuck Norris is already using the final version. He's also the one who edited the original post for more realistic dates. :P

Anyway... I'll do my best to have the demo online this months. i.e. within the next two weeks.

You can reasonably expect a film producer to give you a deadline, but not someone working on something without any constraints. As long as it doesn't end like the DNF story... :P

Amy: Why did you say 5 minutes?


"Why did you say five minutes?!"(Eleven/Amy;Vidlet)

The Doctor: Oops.

 :bravo: :youretheboss: