[AUCTeX-devel] Re: Plea for help - anomalous AUCTeX behavior

[David Kastrup]

Robert Knighten <address@hidden> writes:

> I am presently writing a mathematics book using AUCTeX.  Recently,
> probably after upgrading to AUCTeX version 11.81 on Emacs version
> 21.4.1, I have the problem that Emacs will suddenly and for very
> prolonged periods of time become nearly unusable because of lack of
> response.

[...]

> Sometimes I can solve the problem by restarting Emacs.  On occasion
> I have been able to work on the book for an entire day before the
> problem starts, but at other times it starts immediately.  Here is
> what I have in my .emacs to get AUCTeX working:
> (require `tex-site)  ;; so aucTex will work

The above line is _not_ correct.  If that does not _immediately_ break
AUCTeX, it is likely that you have an old tex-site.el from a previous
installation in your path.  Please use

M-x list-load-path-shadows RET

to make sure that this is not the case.

> (load "auctex.el" nil t t)
> (setq TeX-auto-save t)
> (setq TeX-parse-self t)
> (setq-default TeX-master 'nil)
> (setq TeX-insert-braces t)
>
> ;; enable reftex with AUCTeX LaTeX mode
> (add-hook 'LaTeX-mode-hook 'turn-on-reftex)
>
> I am not using preview-latex.

Incidentally, preview-latex does not affect editing performance at all
since it does not require processor power between explicit invocations
by key or menu.  If you are creating a mathematics text book, you
should really give it a whirl.  That's pretty much the application it
has been created for.

> Any suggestions about what is going on and how I can correct this
> problem will be appreciated.

One likely culprit is font-locking once you have checked that you have
not a version mixture problem.  font-lock is one of the few things
that work on a per-keystroke base.

If you use font-lock-mode, try turning it off in the buffer with
M-x font-lock-mode RET

If that "solves" the problem (at the cost of removing the font
locking), we'll need to dig further into what exactly in the font lock
patterns and code is responsible for the problem.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum