[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8789: 23.3; debug backtrace buffer changes window on step-through
From: |
Eli Zaretskii |
Subject: |
bug#8789: 23.3; debug backtrace buffer changes window on step-through |
Date: |
Thu, 20 Sep 2012 21:30:47 +0300 |
> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Thu, 20 Sep 2012 11:08:26 -0700
> Cc: 8789@debbugs.gnu.org
>
> > > It's caused by the calculation of the mode-line. Try this:
> > > (setq-default mode-line-remote nil)
> > > and the problem is gone.
> >
> > So the solution is probably to never enable `debug-on-entry' for
> > functions that run through the mode-line mechanism.
>
> That does not sound like the solution to me.
Please suggest another solution, then, for a function that is
constantly called as part of redisplay (which is what happens here,
see below). AFAIU, this is why you "cannot exit the debugger":
anything that you do redisplays the mode line, and re-enters the
debugger.
> What does "run through the mode-line mechanism" even mean,
It means functions that are called when some Lisp form is evaluated as
part of displaying the mode line.
> and how does a user tell whether a given function might "run through..."?
By examining the C-level call stack, I presume.
> And
> for such functions (whatever that might mean), what workaround do you propose,
> to get the effect of `debug-on-entry'.
Why do you need a work-around? The feature works, it just has nasty
side-effects due to the fact that the function is constantly called.
> This is a regression, and should just be fixed.
How do you "fix" situation where a function you want to debug is
called at a very high frequency? The only way I know if is to stop
calling it -- which is precisely what was suggested: set
mode-line-remote to nil, which avoids the invocation of file-remote-p
as part of mode-line redisplay.
> > M-x debug-on-entry file-remote-p
> >
> > That puts me immediately into the debugger, with a call to
> `file-remote-p'. Why
> > does debugging file-remote-p cause the debugger to enter even for that M-x
> > invocation?
Typing "M-x" causes redisplay of certain parts of the Emacs frame,
including the mode line. And redisplaying the mode line calls
file-remote-p because of mode-line-remote, which puts an indication of
a file being remote on the mode line.
> > There is not even any reading of a file name.
The file name in question is buffer-file-name.
> > Thereafter, I cannot exit the debugger, no matter what I do. `c' and `q'
> seem
> > to do nothing. `d' just steps into `file-remote-p'. Even `C-]' does not
> exit
> > the debugger. I can use C-x k to kill the *Backtrace* buffer, but that
> leaves
> > Emacs in a recursive edit, and `C-]' then brings Emacs back into the
You just re-enter the debugger again and again, and the indication is:
> > After the `C-x k', *Messages* shows this multiple times, always ending by
> > entering:
> >
> > Entering debugger...
> > Quit
> > Entering debugger...
> > Quit
> > Entering debugger...
> > Quit
> > Entering debugger...
> > Quit
> > Entering debugger...
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, (continued)
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/09/19
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/19
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/19
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/19
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Michael Heerdegen, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, martin rudalics, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through,
Eli Zaretskii <=
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Eli Zaretskii, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Stefan Monnier, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Michael Heerdegen, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Eli Zaretskii, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Michael Heerdegen, 2012/09/20
- bug#8789: 23.3; debug backtrace buffer changes window on step-through, Drew Adams, 2012/09/20