Re: BBC Parsing
Reply #76 –
I am thinking about adding another BBC type for footnotes. It would be TYPE_PARSED_CONTENT_COUNTED. Footnotes would be the only type with this and I can't see another type having it, but it would make footnotes not so hacky.
For each tag it would add an element to $counted_bbc with the tag name as the key. For each tag found, it would save that code. So, instead of doing some kludgery with %fn%, you would just save the message stub in the code there and retrieve that later. It would save the count which would get reset for each message and save a total which wouldn't get reset at all. I guess I need to code it out to show you. Maybe "counted" isn't the best term.
hmm... I guess it could also be used it for images to make a gallery at the end of the message.
Re: BBC Parsing
Reply #81 –
I am also thinking that the BBC parser shouldn't handle smileys at all. It should just add the markers for where the smiley parser should/shouldn't parse and then return it. This way you don't have to even include the BBC parser if you don't want to and makes it a lot easier to change the smiley parser and leaves less for the BBC parser to do.
Re: BBC Parsing
Reply #83 –
You just had a typo. I was looking at it for a while.
You probably think you're missing something because the old parser was so much more complex. I thought that it was so much more complicated than it is. The BBC parser adds \n around text that shouldn't be parsed. Then it explode()s the string on those and parses every other element in that array. If parsing is disabled, the smiley parser does the entire message.
Re: BBC Parsing
Reply #85 –
I added the license stuff. Let me know if I missed anywhere. Can I license this project as
Changing out the smiley parser was really easy.
Now there are 4 separate classes for parsing: BBC, HTML, smileys, and links. There will need to be at least one new global. I hope it would be a DIC.
Re: BBC Parsing
Reply #86 –
The latest commit (at the time of me writing this) is the base for a converter. I have had a bit much to drink tonight so I'm not going to continue with it, but I want to make it possible to convert the old format and create new bulletin board codes with a GUI. I realized, quickly, that an exporter will be very limited because I can't (or don't want to do all of the work to) parse the PHP out of the BBC array. What you see now is when I figured that it would be too complicated and needed to change my focus.
Re: BBC Parsing
Reply #88 –
The converter would work fine if I didn't have to worry about anonymous functions and inline conditions. Actually, the converter will still work. I just can't export. So you can add a middleware for the BBC but that's not that same as exporting a new package.
Re: BBC Parsing
Reply #89 –
This idea is about performance. What if, instead of doing autolink() on run, we do autolink() on parsing. We could either add another tag ([autolink]) or add another parameter to url so we know it's an autolink. Then, when we unparse() just remove the tag. Autolink accounts for 7.2% of the total time to parse. That would mean just adding another tag to a message instead of a regular expression (regular expressions are killer on this parser). I think the preferred method is to use another tag because parameters, tests, and regular expressions in general are the slowest part of the entire parser.
Major problem with that is it requires running the regex on all messages when you upgrade. I guess you can do an instr() and look for www. or :// or @ and then return the ID to do the regular expression in PHP.