Re: open large file with C code: is it realy should be so slow?

[Stefan Monnier]

> (not cheques getting cashed), and suchlike.  When I type, sometimes the
> display is quite a few characters behind the keyboard.  But pauses like
> that don't bother me too much; I just carry on typing, subconsciously
> confident that Emacs will cache up soon enough.  But that's just me.

I can live with them as well, but such files were perfectly editable
without any such delays even on much slower processors, not that
long ago.  So I don't think such delays should be considered acceptable,
except in pathological cases.

> I'd guess that C Mode slowed down quite a lot in CC Mode 5.30, when the
> font locking was taken into CC Mode, with the default decoration level
> (3), prioritising accuracy over speed.  Since then, I've added a bit of

It looks like it indeed.  I'm wondering if it was a good decision: maybe
I've just learned to live with the previous inaccuracies, but I have the
impression that I've seen more font-locking errors with the "new"
font-locking than with the old one: maybe it's more accurate, but only
as long as its cache doesn't get out-of-date/garbled.
More specifically, I still regularly see function definitions that are not
properly highlighted (presumably because the cache indicates that it's
not at top-level, even tho it is).

Also accuracy is basically impossible in the presence of funky CPP
macros, and it's already very difficult in actual code, because of
things like

   #if foo
      {
        blabla
   #else
      blibli;
      {
        toto;
   #endif

Emacs has traditionally taken the "shallow" approach, using lexical cues
rather than full blown syntactic analysis, and this has served it fairly
well.  Both approaches have their downsides.


        Stefan