Tracing an unwanted raise-frame()

Tracing an unwanted raise-frame()

[Nordlöw]

Suddenly my Emacs has started to pop-up/raise itself as soon as I
perform a compilation or a debugging event happens. This makes
debugging of graphical applications virtually impossible. So I am
looking for a way to trace this unwanted call to raise-frame(). How
can I do this? Does Emacs have the concept of breakpoints? The problem
of course occurs only with my own add-ons loaded and I don't want to
waste time checking to brute-force trial-and-error check which error
is the cause of the problem.

Thanks in advance,
Nordlöw

Re: Tracing an unwanted raise-frame()

[Johan Bockgård]

Nordlöw <per.nordlow@gmail.com> writes:

> Suddenly my Emacs has started to pop-up/raise itself as soon as I
> perform a compilation or a debugging event happens. This makes
> debugging of graphical applications virtually impossible. So I am
> looking for a way to trace this unwanted call to raise-frame(). How
> can I do this? Does Emacs have the concept of breakpoints? The problem
> of course occurs only with my own add-ons loaded and I don't want to
> waste time checking to brute-force trial-and-error check which error
> is the cause of the problem.

M-x debug-on-entry

-- 
Johan Bockgård

Re: Tracing an unwanted raise-frame()

[Kevin Rodgers]

Nordlöw wrote:
> Suddenly my Emacs has started to pop-up/raise itself as soon as I
> perform a compilation or a debugging event happens. This makes
> debugging of graphical applications virtually impossible. So I am
> looking for a way to trace this unwanted call to raise-frame(). How
> can I do this? Does Emacs have the concept of breakpoints? The problem
> of course occurs only with my own add-ons loaded and I don't want to
> waste time checking to brute-force trial-and-error check which error
> is the cause of the problem.

C-h v special-display-buffer-names
C-h v special-display-regexps

-- 
Kevin Rodgers
Denver, Colorado, USA