GHOP #135 Add an escape mechanism to Glossary module

a) Personally for skipping I would use square brackets [no-glossary]mismatches[/no-glossary], mainly because it's the shortest form I can think of. What do you think about it? Maybe I should do a quick research (ex. contact glossary contributors for opinions)? Also it's easier to implement, and probably faster (than searching for matching </span>s)
b) about glossary-phrases - are overlaping matches the only problem (like in terms C,C++)? If so, glossary terms can include spaces, so it would be enough to, for ex., put every match in 'invisible' <acronym> or [no-glossary] tags.
c) I can't reproduce any match within img tags (<img sth here />), they shouldn't match, because < and > chars are counted. Could you precise the input format and matching settings used?

Sorry for the delay, I ran into troubles trying to profile the code.
I almost entirely rewrote the __glossary_insertlink() function, now it should be faster and a little more 'powerful'.
It doesn't check backward for every match, so it's at least twice as fast on my test site with 20 words in the glossary.
It should use twice less memory for large texts, but it can be really memory-hungry for big glossaries (because it keeps all $ins_after parts in memory), I'll try to fix that (this will probably need moving the 'Find match candidates' part into _glossary_filter_process()).

[no-glossary] tags are implemented, escaping of code tags too.
b) 'cole mining' was also a problem of duplicate matches overlapping, it's fixed now. We don't need a "glossary-phrase" tag, unless we'd like to leave support for overlapping matches too.
c) The only problem I can see with <img> tags is when there are additional '>' chars (ex. used as 'less-than', not as html tags). Now if there is a '<' char, everything will be escaped until a '>' char. Do the <img> tags still not work? Maybe we should skip '<' chars that have whitespace or digits after it?
d) I'm not sure if we need to escape tags that probably won't contain matches (like [% ) ? Another reason is that ex. the GeShi filter allows custom code tags, so code filters should process the text earlier anyway, and then we only need to check for html <code> and <pre> tags. On the other hand it doesn't slow the parsing down that much. So I left the other version commented out on line 539.

Oh, sorry, my mistake.
I've glanced at the differences and I see no problem, I'll update a merged patch in a moment.

I just had a power outage and I still have some troubles with connection :)
I hope this patch works.

Oops, I forgot to rename a variable when merging, which caused the filter to act randomly.
Also there was one bug with multibyte matches and one when matching synonyms.

A bug in parentheses (I think this should have raised a php notice...).

I added a simple setting for custom blocking tags. I removed <acronym> from hard-coded tags (it might have helped earlier to avoid overlapping), and moved it to default custom tags (in case somebody uses them).

As for the documentation, I don't know in what form, where and how much I should write (should I ask for doc edting permissions?), but here's a try:
1. On page A. Installation and Settings (http://drupal.org/node/201760), after Settings>For each input format>Replace matches
2. On the main doc page (http://drupal.org/node/196880) I'd add a pararaph before Issues
3. On the 'Howto: Install glossary module' page (http://drupal.org/node/69583), next to Configuring>Replace Matches

Preview:
1.

2.

Which terms match

When two different terms occur in one place, the longer one will be matched. This way, when you add definitions for 'code' and 'postal code', the phrase 'postal code' will show one definition, different than 'code' alone (of course 'machine code', if not defined, will still show only the definition of 'code'). This also applies when you change the match type (e.g. you can set 'postcode' and 'coder' to have different definitions, even though originally 'code' would match substrings).
If you don't want some text to be filtered for terms at all, enclose it with [no-glossary] [/no-glossary] tags. You can also choose not to inlude glossary links in specific html tags.

3.

Thanks for testing it so thoroughly.

Format/general settings: Different formats have different tags, and though I can't think of any situation where the same tag would be used differently, it may affect performance a little (e.g. we don't want to check for all Full HTML blocking tags in every other format). But that's not a big benefit, and I can't think of a reason against, either (except some usability), so I just thought that all settings which can be format settings do so (global settings don't include settings which affect individual nodes, it seems they only change how glossary pages look).

line 603 should be changed to

- $findtagfunc = $mb_prefix .'stripos';
+ $findtagfunc = $mb_prefix .'strpos';

because mb_stripos seems to be 20 (!) times slower than mb_strpos.