[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
    (require 'bytecomp)

    (defadvice blink-matching-open (around enable-blink-paren-hack activate)
      (let (show-paren-mode) ad-do-it))

     '(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
ad-Orig-blink-matching-open: Lisp nesting exceeds `max-lisp-eval-depth'

A partial backtrace:

Debugger entered--Lisp error: (error "Lisp nesting exceeds

GNU Emacs (i486-pc-linux-gnu, GTK+ Version 2.12.11) of
2008-11-22 on elegiac, modified by Debian

reply via email to

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