[Latest news after some playing around with it again] Couldn't the problem be that we don't invalidate the cache when changing major modes and that somehow now we setup the cache before switching to c-mode, Try C-x b newbuffername1 /* ab (cd) ef */ Cursort to 'e' M-: (buffer-s-context) => nil M-x c-mode M-: (buffer-s-context) => nil (Invalidate the cache by doing something else (like calling b-s-c in another c buffer) M-: (buffer-s-context) => 'block-comment M-x fundamental-mode M-: (buffer-s-context) => 'block-comment !!!! [old news:] Hrvoje Niksic <hniksic(a)srce.hr&gt; writes: Are you sure it is the cache? If it is the cache it is probably this 1998-03-29 Martin Buchholz <martin(a)xemacs.org&gt; * font-lock.c (find_context): Use context_none with context instead of ccontext_none. RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/font-lock.c,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- font-lock.c 1997/09/03 03:39:36 1.2 +++ font-lock.c 1998/03/31 20:11:42 1.3 ＠＠ -432,7 +432,7 ＠＠ if (context_cache.needs_its_head_reexamined) { if (context_cache.depth == 0 - && context_cache.context == ccontext_none) + && context_cache.context == context_none) { /* We've found an anchor spot. The weird thing is, if it is this, why does it matter? Assuming enums are assigned from 0 the difference is only syntactic.