bug#8789: 23.3; debug backtrace buffer changes window on step-through

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <rudalics@gmx.at>, <michael_heerdegen@web.de>, <8789@debbugs.gnu.org>
> Date: Thu, 20 Sep 2012 11:49:43 -0700
> 
> > > > 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.
> 
> Gee, Eli, I don't know what the solution is.  Except maybe to revert the 
> change
> that caused the regression.
> 
> Or maybe the debugger should skip over such mode-line refreshing?  I really
> don't know, sorry.

Well, ideas are certainly welcome.  It's a hard problem, given the
potentially conflicting goals.  I don't think removing the feature
will be welcome.

One such solution already exists: set inhibit-eval-during-redisplay to
a non-nil value (it will inhibit _all_ calls to Lisp by all display
features, though).  I'm not sure how visible is that feature.  Perhaps
we need to advertise it more.

> I do know that there is all kinds of code, including user code, that calls
> `file-remote-p' - if nothing else, to avoid tramp digging in its heels and
> trying to access remote machines.  If we cannot debug such code without first
> manually fiddling with the mode-line spec, then that's a sorry situation, 
> IMHO.

This is a potential problem with any code, C or Lisp, that runs during
each redisplay cycle.  On the C level, the only sane way of dealing
with this is to use conditional breakpoints with cleverly designed
conditions that cause the breakpoints break only when the function
being debugged is called in the right context, bypassing the myriads
of irrelevant calls.

> I would say that it is indeed unfortunate if we are now calling 
> `file-remote-p'
> as part of displaying the mode line.

Surely, there's nothing special in 'file-remote-p', except the fact
that you needed to debug it in this case.  Any code that is eval'ed as
part of displaying the mode line, or redisplay in general, will be
susceptible to similar problems.  A solution specific to a single
function won't do, would it?

> > > 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?
> 
> It should not be called for mode-line display.  IMHO.  That was a misguided
> enhancement.

I disagree.  That indication is important when you work with remote
files a lot.  And again, this particular function is not the issue;
the issue is more general.

> > 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.
> 
> Not as an individual user - that's just Emacs Dev punting.

When you debug, you _are_ a developer.

> Perhaps the debugger could do that automatically.

Not unconditionally, because it is perfectly valid to debug code that
runs off redisplay.

> Whether it should or not, and whether that should be a user option,
> I also don't know.  But we should not expect users to dig in and
> discover this stuff and work around it on an individual basis.

Even if we have an option (please see if inhibit-eval-during-redisplay
suits your needs), using it already requires to know or suspect that
calls from redisplay are the reason for "strange" behavior during
debugging.  So I'm not sure I see how any such option will solve the
problem of discoverability; again, ideas welcome.