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

[Drew Adams]

> > 3. But I also think that it should be enough, for this 
> > problematic mode line enhancement, to simply call a
> > duplicate of `file-remote-p' and not `file-remote-p'
> > itself, which is used by all kinds of code.
> > 
> > If that duplicate (e.g., `mode-line-file-remote-p') is 
> > called only by the mode-line code then that should
> > greatly reduce, if not eliminate, this problem
> > for the debugger.
> 
> This has 2 problems, at least:
> 
>  . what if I need to debug mode-line-file-remote-p?

Just do it.  With the same problems you encounter today - no more and no less.

The point is that the number of people who would, today, fall upon this
`file-remote-p' sword accidentally _far_ outnumbers the people who will need to
debug `mode-line-remote-p'.  And those in the latter group will be likely to do
so with cognizance of cause.  Not so those in the first group.

That's the (should-be-obvious) point: `file-remote-p' is called all over the
place, by code that has nothing at all to do with the mode line or redisplay.
`mode-line-file-remote-p' would have as its raison d'etre to be called only by
mode-line code.

>  . what about calling Lisp from display features other than the mode
>    line, such as tool-bar buttons and menu items?

Hey, I have nothing against your coming up with an elegant, general solution.
But while waiting, why not solve the problem at hand?  If you later manage to
square the circle, then you can rename `mode-line-file-remote-p' back to
`file-remote-p'.  Easy.

> In general, I think this is a slippery slope: before long we will be
> duplicating many important functions, and we will have to enforce some
> kind of coding standards whereby redisplay features cannot call
> "ordinary" functions.  I think this is absurd.

You are exaggerating.

If you have a better, immediate solution, please go for it.  Or if you want to
revert the change that caused the regression, go for it.

But if you just want to wave your hands wildly about this not being the only
problem, then I say, again, let's not let the perfect become the enemy of the
good.

In sum, I do not claim that my suggestion is the only or the best possible
solution.  Better ideas are welcome.  But let's not avoid solving the problem
just because there are potentially other, similar problems.