Re: Point of wrong window used in read-from-minibuffer?

[Stefan Monnier]

> It happens that the current buffer's own value of point is unchanged
> through this process, because save-window-excursion is not supposed to
> restore that.  It is supposed to leave that value alone, and it does.
> (Or rather, it did so before you made a change.)

AFAIK my change did not affect this, at least any more than
a (sit-for 0).

> I agree that the current behavior is counterintuitive in this case.
> Perhaps a different behavior would be better.  However, in order to
> consider a different behavior, we have to have a clear picture of it.
> What behavior does your patch result in?  We need to be able to
> document it clearly and in general.

My patch tries to make save-window-excursion behave more like select-window
(and save-selected-window, and with-selected-window).  The main motivation
behind select-window's behavior is:
- first try not to move any window's point.
- second try not to not move current-buffer's point.
whereas save-window-excursion puts more emphasis on the second than on
the first.  I think select-window's behavior is more correct since end users
see windows's points, not buffers's points.

> Also, there's the possibility that this change will break some code.

Indeed, that's why I haven't installed it.

> Some uses of save-window-excursion expect to do (goto-char ...) inside
> the save-window-excursion and have point still be at that place
> outside the save-window-excursion.  That's the kind of case that this
> patch could break.

Could you give an example where that would happen?

> Maybe there are no cases that in fact would break.  Maybe the places
> that do that don't switch windows in a way that could cause trouble.
> But it leads me to ask: does putting (save-excursion ...) around
> the call to save-window-excursion fix the problem?

Which problem?  There are two distinct situations where
save-window-excursion doesn't behave the way I'd expect: one of them caused
a problem in the OP's case and I fixed it because I think it qualifies as
a plain bug.  The other is examplified by (save-window-excursion
(select-window (next-window))) but I don't know yet when/where it actually
bites us (another reason why I haven't installed my suggested patch for
this problem).
The two fixes are independent: the first is for when
set-window-configuration changes current-buffer the second is for when
current-buffer is unaffected.


        Stefan