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

[Drew Adams]

> 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.

More than what? ;-)  I never heard of it.  And it does not appear to be
documented in the Elisp manual.

But how about an option that does that only for eval when the debugger is
active?  IOW, that sounds like something that is a broader brush than what is
needed here.

> 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.

No, of course there is nothing special about it.  The point is that it is a
commonly called function, and now it is also called to display the mode line.
That is a powder-keg combination.  That is the problem.  It is asking for
trouble to call such a function as part of the mode-line display.

> Any code that is eval'ed as
> part of displaying the mode line, or redisplay in general, will be
> susceptible to similar problems.

Precisely.

> A solution specific to a single function won't do, would it?

It would do for this particular bug. ;-)  But yes, the same principle and
potential problem applies to all functions called during display of the mode
line (or other redisplay stuff).

> > > > 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.

No one said it was not useful.  In fact, I explicitly said it was.

> And again, this particular function is not the issue;
> the issue is more general.

Yes and no.  Agreed that there is a general problem.  But let's not let the
perfect become the enemy of the good.

This particular regression was introduced because `file-remote-p' is now called
to update the mode line.  Take care of that bug and you take care of that bug
;-), which is already a good thing.

> > Perhaps the debugger could do that automatically.
> 
> Not unconditionally, because it is perfectly valid to debug code that
> runs off redisplay.

Agreed.  That's why I mentioned doing so optionally (and probably by default, to
lessen surprise).

> > 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.

Make it not only optional, but the default behavior for the debugger.  No, I do
not mean `inhibit-eval-during-redisplay', which paints with a broader brush.  I
mean an option to have the debugger skip over/through calls involving redisplay.

But you ignored the simple solution I proposed: just make the mode-line code
call a separate function from `file-remote-p'.  That function can do the same
thing, and it could even have exactly the same definition.  But it would be
called out as being something that is intended to be called only by the
mode-line code.  IOW, try to keep this separate and make that intention
explicit.

It seems to me that that would go a long way - maybe all the way - to preventing
typical debugging from falling down the hole that this discussion is about.