[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Strange interaction between three seemingly unrelated components
From: |
Geoff Gole |
Subject: |
Strange interaction between three seemingly unrelated components |
Date: |
Sat, 28 Mar 2009 23:08:49 +0900 |
Various parts of my .emacs evaluate some seemingly unrelated bits of
code that behave strangely when evaluated in a certain order. The
minimal example seems to be:
emacs -Q
(progn
(require 'bytecomp)
(defadvice blink-matching-open (around enable-blink-paren-hack activate)
(let (show-paren-mode) ad-do-it))
(custom-set-variables
'(uniquify-buffer-name-style (quote post-forward-angle-brackets)
nil (uniquify)))
(defadvice blink-matching-open (around enable-blink-paren-hack activate)
(let (show-paren-mode) ad-do-it)))
This sequence corresponds to loading .emacs at startup, making a small
unrelated change, then loading it again. After the code has run
blink-matching-open is thoroughly broken, recursing infinitely if
invoked (such as by typing a close paren). Both the order of the code
and the contents of the custom-set-variables form seem to be necessary
for that to occur.
I don't understand this at all. Why would (require 'bytecomp),
defadvice and custom-set-variables interact in this way? How might I
debug this bizarre problem?
*Messages* tells me:
ad-handle-definition: `blink-matching-open' got redefined
blink-matching-open
ad-Orig-blink-matching-open: Lisp nesting exceeds `max-lisp-eval-depth'
A partial backtrace:
Debugger entered--Lisp error: (error "Lisp nesting exceeds
`max-lisp-eval-depth'")
ad-Orig-blink-matching-open()
ad-Orig-blink-matching-open()
ad-Orig-blink-matching-open()
etc
Version:
GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of
2008-11-22 on elegiac, modified by Debian
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Strange interaction between three seemingly unrelated components,
Geoff Gole <=