I can confirm this. But I do not understand, why you consider this a bug? Only typing '/*' opens an opening comment. The highlighting get's updated by typing the '/' char and because an opening '/*' needs a closing '*/', the highlighting is wrong. But closing the comment with '*/' updates the highlighting again and everything should be ok then. I can remove the '/' char from the list of "update-highlighting"-patterns if you want. But there is no bug inside the highlighting pattern itself. Please tell me, what you think about this.

Solution for the furute: Maybe we should add an autocompletion feature for such strings.

Severity was set to enhancement and priority to low.

I see your point, but apparently you were not experiencing the same as me.
The problem is, that the other code stays this way, even after closing a block.

At some places in the code it works just as you say.
As far as i know now, this bug only can appear in the last 5 or 6 lines of a PHP-Block. Isn't that exactly the count of lines which is marked as a comment already when u just open a block comment in C-style? It think it is.
So it has to do something with that. And you are right, the mistake probably doesn't lie in one of the patterns. 

P.S.

A more detailed description of what effect it does have:
 When opening the block comment and hit space the bug as mentioned in the initial bug report appears (partially wrong highlighted code above).
 When closing the comment everything from 5 lines above to the end of the PHP-Block isn't highlighted anymore at all. 
 

Hmm. When I read your comment, I was thinking, that your problem is maybe related to "Highlight # lines" in preferences. What did you choose there?

I forgot to say that the major problem with this bug is,
that the highlighting won't fix automatically after the bug happens.
This means you can write hundreds of lines of codes and the highlighting doesn't work for the part which follows after the "buggy" comment block anymore. 
As i said most of the code above that the code is partially highlighted.
And if u change something in that part of the code the bug "runs rampant like a desease". Because 5 lines above and below the line you change something the syntax highlighting falls off completely just like everything below the initial buggy comment block.
To fix it i have to hit F5 everytime this bug appears, which is comparetively often since it happens every time you are using comments or strings.
So maybe a solution for this bug would be to update syntax highlighting just as it is done by pressing F5 after closing a comment block / string (within the last 5 or 6 lines of a PHP-Block).

I hope this made things clearer now. If you still don't understand my point certainly my bad English is the problem anyway. :'-)

Ok. I can reproduce the bug. Simple example. Begin with

<?php
?>

Not add
/* line1 [ENTER]
 * line2 [ENTER]
 * line3 [ENTER]
 * line4 [ENTER]
 * line5 [ENTER]
 * line6 [ENTER]
 * line7 [ENTER]
...
 */

Exact after line n with n='Highlight # lines', automatic highlighting fails. So the workaround for you is, to encrease this number. This should work for the moment.

Increasing that number does expand effects of the bug in fact. 
Since it means that not only 5 lines are effected, but 8 (which is the highest number that can be set within Bluefish settings, apparently).
The solution for me is therefore to set this number to 1. 

I just tried it out and it seems to work perfectly allright now.

Created attachment 58415 [details]
Screenshots of the bug

If you look at the screenshots in the correct order from 1 to 4 you will clearly see what effects this bug has.

Workaround committed by Jim:

http://cvs.sourceforge.net/viewcvs.py/bluefish/bluefish-gtk2/data/Attic/highlighting.in?r1=1.52.2.24&r2=1.52.2.25&only_with_tag=bluefish_1_0

This should solve the bug for you.

Yes, that solves the problem for block comments in C-style.
There is still the problem with [single|double] quoted strings, though.

Well and the solution for this bug to me anyway is to set "Highlight # Lines" to 1, as i couldn't make out any differences in bahavior when this is set to 5.

However thanks for help, now i can really USE Bluefish for web development.

Hmm, I don't see the issue with single/double quoted strings. Unlike the C comment issue the highlighting is updated as soon as you close the string.

Is there a different problem with strings?

Hmm. I also see weired behaviour with strings. But applying a pattern change similar to the one you used for C-comments, the problem is going away. Shall I submit it?

--- data/highlighting.in        31 Jan 2006 04:28:26 -0000      1.52.2.25
+++ data/highlighting.in        31 Jan 2006 14:17:02 -0000
@@ -166,11 +166,11 @@
 php:Keywords:0:\\b(return|goto|global|var|class|function|new)\\b::2:^PHP Block$:#000000::2:0:
 php:Braces:0:[{()}]::2:^PHP Block$:#000000::2:1:
 php:Brackets:1:[\\[\\]]::2:^PHP Block$:#0000cc::2:0:
-php:String (double quoted):0:":":1:^PHP Block$:#009900::1:1:
+php:String (double quoted):0:".*?"::2:^PHP Block$:#009900::1:1:
 php:String (double quote escaped):0:\\\\.::2:^String \\(double quoted\\)$:::1:1:
 php:Variables:1:\\$?\\$[a-z_][a-z0-9>_$-]*::2:^PHP Block$:#cc0000::2:0:
 php:Variables (special characters):0:(\\[|\\]|->)::2:^Variables$:#0000cc::2:0:
-php:String (single quoted):0:':':1:^PHP Block$:#009900::1:1:
+php:String (single quoted):0:'.*?'::2:^PHP Block$:#009900::1:1:
 php:String (single quote escaped):0:\\\\.::2:^String \\(single quoted\\)$:::1:1:
 php:Comment (C):0:/\\*.*?\\*/::2:^PHP Block$:#7777aa::1:2:
 php:Comment (C++/single line):0:(//|#).*?$::2:^PHP Block$:#7777aa::1:2:

Submitted (data/highlighting.in:  1.52.2.25 -> 1.52.2.26). Clsoing this bug now, because the updated pattern should fix the objectionable issues.