Re: Unbearably slow editing in .h files

[Stefan Monnier]

> ;-)  I think that lisp.h is an ill-conditioned file, in some way.  Or
> are you telling me that the slowness happens in a lot of files.h?

Basically, all .h files, tho clearly the slowdown is proportional to the
distance between point-min and point.

> The intolerability could be due to searching for an unnested brace
> instead of one at column zero.

Could be.  Tho I don't see why it should be so slow, and if it is, then
I'm convinced there's got to be some heuristic we could use to eliminate
the O(N) complexity in practice.
E.g. (re-search-backward "[;}][ \n\t]*\n[^ \t]") combined with
a syntax-ppss check to make sure we're not inside a string/comment/parens.

> Which files.h are you talking about, Stefan?  CC Mode seems to work well
> enough for me in my day job (maintaining typical old
> "proprietary-quality" C code).  Maybe .../src/lisp.h and one or two
> others are somewhat extreme in their use of macros, or something.  A

My machine is not slow, but my Emacs is compiled with a fair bit of
extra debugging checks, so it's equivalent to running on a slow machine.
Still, the slowness is usually unnoticeable.


        Stefan


PS: One other problem with add-log-current-defun is that it does not
recognize function declarations any more (i.e. hitting C-x 4 a
on a line like

  void foo (int);

will fail to find the "foo" to put it in the ChangeLog).  Not sure if
it's related.