[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unbearably slow editing in .h files

From: Stefan Monnier
Subject: Re: Unbearably slow editing in .h files
Date: Sat, 23 Feb 2008 19:37:17 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

> ;-)  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.


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]