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

[Drew Adams]

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

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.

What users will even be aware that they will need to fiddle with such a
workaround?  A user stepping through code that happens to call `file-remote-p'
at some point will be quite surprised, and will typically have no clue what to
do at that point.

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

I would say that it is indeed unfortunate if we are now calling `file-remote-p'
as part of displaying the mode line.  Sure, individual users can remove that.
And sure, having an indication in the mode line of whether or not something is
remote is nice.  But if this is the price then I'd say we should find some other
solution - i.e., some other way to add that feature.

If nothing else, it might be enough to duplicate the code for `file-remote-p' as
`mode-line-file-remote-p', and use only the latter for mode-line update.  That
should reduce interference with most Elisp code.

I don't claim that is the best way to handle this.  My point is that we should
not have mode-line updating invoke `file-remote-p', if that means that breaking
debugging, so that the debugger barfs and rebarfs whenever it invokes
`file-remote-p'.

> > and how does a user tell whether a given function might 
> "run through..."? 
> 
> By examining the C-level call stack, I presume.

Wunderbar.  Lisp debugger users now need to dig deeper into the bowels of Emacs.

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

IOW, it works but it just doesn't work, in practice.

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

> 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.  Perhaps the debugger
could do that automatically.  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.