I am sorry about that "I suggest someone..." Sounds rude. I know most people do this for fun and don't get paid at all. Nevertheless, it is quite a serious bug and I am not the man to hack the libs I am afraid.

I'll bet you the problem is r655086 (if you're talking about /trunk), from bug 135844. Christoph also reported a problem with the ported patch and php, but I was unable to reproduce it. So if you can attach to this bug a .php that demonstrates the problem, that would be really helpful!

Are you talking about trunk or branch? Does r654968 still work or is it the first that does not work anymore?

The error does not occur at 654968 but occurs at the next commit 655056.

This is the BAD one, and it isn't trunk if that is unclear:
jonas@jw ~/kdesvn/kdelibs/kate $ svn info
Path: .
URL: svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kdelibs/kate
Repository Root: svn://anonsvn.kde.org/home/kde
Repository UUID: 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Revision: 655056
...

the file changed between those commits is:
/branches/KDE/3.5/kdelibs/kate/part/katehighlight.cpp


I have some more bug reproduction info for you.
Kate seems to dislike the way PHP context is opened with the <? sequence.
When using revision 655056 or later, you get this:

1
Open a fresh kate, empty session. kate creates an "Untitled" buffer (or whatever the term is, document, empty file, etc.).
Kate selects highligting "None".

2
select HTML highlighting.

3
enter the string <? anywhere, nothing unexpected happens.

4
delete everything

5
select PHP highlighting

6
enter the string "< ?" (note the space!), nothing unexpected happens.

7
delete everything.

8
enter "<?" using PHP highlighting. 
The < makes it, but when you press ? kate hangs and ? is never displayed.
This also goes for "< ?" when you delete the space. Kate hangs before the space gets deleted.

Hope that helps.

In an act of "start over from scratch" yesterday, I rm -rf'd the whole KDE source and build shebang, and everything I have is completely from SVN yesterday,except from the operations I did according to above comments.
I used kdesvn-build 1.3 to build retrieve and build everything.

The essential lines from my ~/.kdesvn-buildrc:
*********************************
global
   use-stable-kde true
   binpath /usr/lib/ccache/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
   source-dir ~/kdesvn
   qtdir ${source-dir}/build/qt-copy
   configure-flags --enable-debug
   cxxflags -pipe
   kde-languages sv
   kdedir /home/kdesvn-installation
end global
module kdelibs
   use-unsermake true
   configure-flags --enable-sendfile --enable-mitshm --with-hal
end module
*********************************

That's all I know.
Can there be any kate settings you'd be interested of?

Confirmed, thanks for the reproduction info!
This does apply to /trunk also, the same steps hang KWrite in /trunk.

FTR: The problem is that r655056 caused KATE to no longer correctly resolve the non-IncludeRules context reference '##PHP/PHP'. As of writing, we're debating if this is even legal syntax, but it reveals a real problem; a look-ahead rule that pushes the current context leads to an infinite loop. Regardless of the decision on external context references outside of IncludeRules, this clearly shouldn't be allowed. :-)

*** Bug 144729 has been marked as a duplicate of this bug. ***

SVN commit 658529 by mwoehlke:

CCBUG: 144599
Ignore rules that would lead to a recursive context stack (i.e. ones that push the top context without eating any characters).


 M  +4 -0      katehighlight.cpp  


--- branches/KDE/3.5/kdelibs/kate/part/katehighlight.cpp #658528:658529
@@ -1452,6 +1452,10 @@
 
       if (offset2 <= offset)
         continue;
+      // BUG 144599: Ignore a context change that would push the same context
+      // without eating anything... this would be an infinite loop!
+      if ( item->lookAhead && item->ctx == ctxNum )
+        continue;
 
       if (item->region2)
       {

SVN commit 658530 by mwoehlke:

BUG: 144599
Ignore rules that would lead to a recursive context stack (i.e. ones that push the top context without eating any characters).


 M  +4 -0      katehighlight.cpp  


--- trunk/KDE/kdelibs/kate/part/katehighlight.cpp #658529:658530
@@ -1423,6 +1423,10 @@
 
       if (offset2 <= offset)
         continue;
+      // BUG 144599: Ignore a context change that would push the same context
+      // without eating anything... this would be an infinite loop!
+      if ( item->lookAhead && ( item->ctx.pops < 2 && item->ctx.newContext == ( ctx.isEmpty() ? 0 : ctx.last() ) ) )
+        continue;
 
       if (item->region2)
       {

I just want to check with you mwoehlke if you are aware that the PHP higlighting is gone now. Everything inside <?php and ?> is black on white for me. I do not intend to reopen this specific bug but it clearly isn't completely busted yet as the fix was a bit, hmmm, coarse... :)

jonas@jw ~/kdesvn/kdelibs/kate $ svn info
Path: .
URL: svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/kdelibs/kate
Repository Root: svn://anonsvn.kde.org/home/kde
Repository UUID: 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Revision: 658946
Node Kind: directory
Schedule: normal
Last Changed Author: mwoehlke
Last Changed Rev: 658551
Last Changed Date: 2007-04-27 19:55:51 +0200 (Fri, 27 Apr 2007)
Properties Last Updated: 2007-04-27 22:27:27 +0200 (Fri, 27 Apr 2007)

Bummer. Either the highlighter is broken or KATE needs to universally handle '[foo]##bar' context references (i.e. including outside of IncludeRules).

Anyway, if anything bug 135844 should be re-opened, looks like the patch needs to be improved unless we want to change the arguably broken *-php.xml's.

But if allowing 'foo##bar' anywhere is as easy as I am suspecting it might be, IMO it makes sense to just support it fully, as per the Principle of Least Surprise.

SVN commit 661206 by mwoehlke:

CCBUG: 135844
CCBUG: 144599
Try to recognize 'foo##bar' contexts in regular context redirects, i.e. in places that are not IncludeRules. This mostly but not entirely works, see bug 145052 and the FIXME added.


 M  +5 -2      katehighlight.cpp  


--- branches/KDE/3.5/kdelibs/kate/part/katehighlight.cpp #661205:661206
@@ -2367,9 +2367,12 @@
 
   else if ( tmpLineEndContext.contains("##"))
   {
-    QString tmp=tmpLineEndContext.mid(tmpLineEndContext.find("##")+2);
+    int o = tmpLineEndContext.find("##");
+    // FIXME at least with 'foo##bar'-style contexts the rules are picked up
+    // but the default attribute is not
+    QString tmp=tmpLineEndContext.mid(o+2);
     if (!embeddedHls.contains(tmp))  embeddedHls.insert(tmp,KateEmbeddedHlInfo());
-    unres=tmpLineEndContext;
+    unres=tmp+':'+tmpLineEndContext.left(o);
     context=0;
   }
 

(forgot to CCBUG this...)
SVN commit 662625 by mwoehlke:

Try to recognize 'foo##bar' contexts in regular context redirects, i.e. in places that are not IncludeRules. This mostly but not entirely works, see bug 145052 and the FIXME added.


 M  +6 -3      katehighlight.cpp  


--- trunk/KDE/kdelibs/kate/part/syntax/katehighlight.cpp #662624:662625 @@ -2403,11 +2403,14 @@
    * handle the remaining string, this might be a ##contextname
    * or a normal contextname....
    */
-  if ( tmpLineEndContext.startsWith("##"))
+  if ( tmpLineEndContext.contains("##"))
   {
-    QString tmp=tmpLineEndContext.right(tmpLineEndContext.length()-2);
+    int o = tmpLineEndContext.indexOf("##");
+    // FIXME at least with 'foo##bar'-style contexts the rules are picked up
+    // but the default attribute is not
+    QString tmp=tmpLineEndContext.mid(o+2);
     if (!embeddedHls.contains(tmp))  embeddedHls.insert(tmp,KateEmbeddedHlInfo());
-    unres=tmp;
+    unres=tmp+':'+tmpLineEndContext.left(o);
     kDebug(13010) << "unres = " << unres << endl;
     context=0;
   }