I just installed Emacs 23.1 (Mac OS, if that matters), and I noticed that the *SLIME Compilation* buffer's fontification became horribly slow. Whenever I run slime-compile-defun, for example, I get this:
Fontifying *SLIME Compilation*... (regexps...............................................)
Whereas the compilation itself takes "0.00 secs" according to the messages, this fontification takes probably 3-5 seconds. This never happened under Emacs 22.3.
I tried disabling everything in my .emacs.d/init.el file, and I also tried turning off everything in slime-setup except the REPL:
(slime-setup '(slime-repl))
No dice, it's all still slow. SLIME is latest from CVS. Is there anything I can do to fix this?
On Tue, 11 Aug 2009, Constantine Vetoshev wrote:
Date: Tue, 11 Aug 2009 11:15:48 -0400 From: Constantine Vetoshev gepardcv@gmail.com To: slime-devel@common-lisp.net Subject: [slime-devel] Emacs 23 and slow compilation output
I just installed Emacs 23.1 (Mac OS, if that matters), and I noticed that the *SLIME Compilation* buffer's fontification became horribly slow. Whenever I run slime-compile-defun, for example, I get this:
Fontifying *SLIME Compilation*... (regexps...............................................)
Whereas the compilation itself takes "0.00 secs" according to the messages, this fontification takes probably 3-5 seconds. This never happened under Emacs 22.3.
I tried disabling everything in my .emacs.d/init.el file, and I also tried turning off everything in slime-setup except the REPL:
(slime-setup '(slime-repl))
No dice, it's all still slow. SLIME is latest from CVS. Is there anything I can do to fix this?
-- Regards, (concatenate Constantine Vetoshev 'string (mapcar #'code-char (reverse '(109 111 99 46 108 105 97 109 103 64 118 99 100 114 97 112 101 103))))
Just a thought... maybe try compiling emacs 23 without xft support (if that is an option on a Mac). You lose antialiasing; you gain font control via ~/.Xdefaults, and probably much faster font rendering.
I have been noticing some pretty big bugs in emacs 23. For instance, if I want to customize some options, a *Customize Apropos* buffer gets opened, but the contents do not end up there, but instead they get written to whatever buffer I had on top at the time. My point is that the problem may be emacs 23, not slime. Emacs 23 is certainly a variable, at any rate.
Carlos
* Carlos Konstanski [2009-08-11 17:39+0200] writes:
Just a thought... maybe try compiling emacs 23 without xft support (if that is an option on a Mac).
Running Emacs in a terminal with emacs -nw is probably easier than recompiling.
You lose antialiasing; you gain font control via ~/.Xdefaults, and probably much faster font rendering.
I think .Xdefaults also works with true-type fonts e.g.: Emacs.Font: DejaVu Sans Mono-10
Helmut
On Tue, 11 Aug 2009, Helmut Eller wrote:
Date: Tue, 11 Aug 2009 18:37:07 +0200 From: Helmut Eller heller@common-lisp.net To: slime-devel@common-lisp.net Subject: Re: [slime-devel] Emacs 23 and slow compilation output
- Carlos Konstanski [2009-08-11 17:39+0200] writes:
Just a thought... maybe try compiling emacs 23 without xft support (if that is an option on a Mac).
Running Emacs in a terminal with emacs -nw is probably easier than recompiling.
You lose antialiasing; you gain font control via ~/.Xdefaults, and probably much faster font rendering.
I think .Xdefaults also works with true-type fonts e.g.: Emacs.Font: DejaVu Sans Mono-10
Helmut
I failed to mention that I have been fighting with a particular font in emacs 23: the lisp machine font. It is not a true type font. It never shows up in the usual GTK or QT font selector widgets. xfontsel is the only gui font chosser tool that recognizes it. I just went back to the web page (http://www.eurogaran.com/downloads/lispmfont/) and tried again. Using these instructions, I got it to work even with xft!
(create-fontset-from-fontset-spec "-lispm-fixed-medium-r-normal-*-13-*-*-*-*-*-fontset-lispm, ascii:-lispm-fixed-medium-r-normal-*-13-*-*-*-*-*-*-*, latin-iso8859-1:-lispm-fixed-medium-r-normal-*-13-*-*-*-*-*-*-*, latin-iso8859-15:-lispm-fixed-medium-r-normal-*-13-*-*-*-*-*-*-*")
(set-default-font "fontset-lispm")
Carlos
Helmut Eller heller@common-lisp.net writes:
- Carlos Konstanski [2009-08-11 17:39+0200] writes:
Just a thought... maybe try compiling emacs 23 without xft support (if that is an option on a Mac).
Running Emacs in a terminal with emacs -nw is probably easier than recompiling.
I tried emacs -nw and Slime compilation went back to its usual snappiness. I also tried recompiling the package without xft, but that did not make a difference.
If i properly remeber, this was a problem with maven (? - i need to look at work) regex in compilation mode
Constantine Vetoshev at "Tue, 11 Aug 2009 11:15:48 -0400" wrote:
I just installed Emacs 23.1 (Mac OS, if that matters), and I noticed that the *SLIME Compilation* buffer's fontification became horribly slow. Whenever I run slime-compile-defun, for example, I get this:
Fontifying *SLIME Compilation*... (regexps...............................................)
Whereas the compilation itself takes "0.00 secs" according to the messages, this fontification takes probably 3-5 seconds. This never happened under Emacs 22.3.
I tried disabling everything in my .emacs.d/init.el file, and I also tried turning off everything in slime-setup except the REPL:
(slime-setup '(slime-repl))
No dice, it's all still slow. SLIME is latest from CVS. Is there anything I can do to fix this?
* Constantine Vetoshev [2009-08-11 17:15+0200] writes:
No dice, it's all still slow. SLIME is latest from CVS. Is there anything I can do to fix this?
Hmm... this sounds like this bug: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3441 but that was fixed before the release.
How many messages are in the compilation buffer? Do you have some unusual filenames?
500 messages take about 10-15 seconds here. Most of the time is spent in creating the overlays in the buffer and sorting the messages. font-locking looks quick: about 1 sec.
With 30 messages some messages flicker in the echo area but it's over after one second or so.
Helmut
Helmut Eller heller@common-lisp.net writes:
Hmm... this sounds like this bug: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3441 but that was fixed before the release.
Fascinating. It's certainly related. I tried this:
(setq compilation-error-regexp-alist nil) (setq compilation-error-regexp-alist-alist nil)
Which reduced the delay significantly. The minibuffer flickers a bit while displaying the "fontifying" message, but this made things usable again. Thanks :)
Is there an easy way to prevent SLIME compilation messages from getting fontified using those regexps at all? I'm hoping for a lighter-weight solution than just clobbering these variables.
How many messages are in the compilation buffer?
None, actually. The compilation buffer just says "0 compiler notes:".
Do you have some unusual filenames?
Not at all. 5-10 characters, all ASCII letters.
* Constantine Vetoshev [2009-08-12 23:20+0200] writes:
Helmut Eller heller@common-lisp.net writes:
Hmm... this sounds like this bug: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=3441 but that was fixed before the release.
Fascinating. It's certainly related. I tried this:
(setq compilation-error-regexp-alist nil) (setq compilation-error-regexp-alist-alist nil)
Which reduced the delay significantly. The minibuffer flickers a bit while displaying the "fontifying" message, but this made things usable again. Thanks :)
Is there an easy way to prevent SLIME compilation messages from getting fontified using those regexps at all? I'm hoping for a lighter-weight solution than just clobbering these variables.
Unfortunately not. Perhaps you can remove only some of the inefficient regexp.
You can also set slime-compilation-finished to nil to disable the compilation log buffer entirely. You would still get the annotations in the source buffer.
I tried emacs -nw and Slime compilation went back to its usual snappiness. I also tried recompiling the package without xft, but that did not make a difference.
Are you sure that this is the same Emacs? If the slowness is caused by the regexp then the terminal version would also be effected.
Helmut
-
Alex Ott -
Carlos Konstanski -
Constantine Vetoshev -
Helmut Eller