Re: xref window switching problems

[Ingo Lohmar]

On Wed, Aug 05 2015 15:33 (+0300), Dmitry Gutov wrote:

> On 08/04/2015 10:42 PM, Ingo Lohmar wrote:
>
>> - the point of the *current* window is moved to the target location
>>    (just what the user wanted to avoid, I suppose)
>
> That's clearly a bug. Should be fixed now, thanks.

Awesome, thanks.

>
>> - when the current window is the only one showing the buffer in
>>    question, then the same buffer is newly displayed in another window we
>>    pop to (hence at the same position)
>
> Aside from the bug above, this seems to be the intended behavior.
>

This was to say that at that point, *neither* of the two windows showed
the original position.  In any case, the behavior is definitely fixed
now.

>> - when another window already shows the same buffer, we pop to this
>>    buffer --- less annoying, but still unexpected and not helpful
>
> I'm not sure if it's a problem, actually. That's how pop-to-buffer
> works. In general, it would even use the current window if it already
> displays the buffer in question, but for
> xref-find-definitions-other-window, we explicitly ask it to use another
> window. So it uses the other window displaying the same buffer.
>
>> The old pre-xref elisp implementations and the tags functions got the
>> "...-other-window" behavior right IMO: Leave my current window's buffer
>> and point alone in any case, and pop to the target shown in another
>> window.
>
> Are you sure it doesn't reuse the second window that displays the same
> buffer?
>

Maybe I was not expressing my thoughts clearly.  Reusing the second
window is what the functions did, and that's just fine --- only the
current window when calling the command should be left alone (and now,
it is).

>> The change would be easy (see xref--pop-to-location), first get the
>> buffer, then do the window business, and only then xref--goto-location.
>
> The choice of how to implement it was not so easy. Pretty much because
>
> (with-current-buffer (current-buffer) (goto-char (point-min)))
>
> moves point in the current window.
>

Except for factoring out xref--goto-char, your patch looks just like my
private testing.

>> Maybe xref-pop-marker-stack could benefit from a discussion as well.
>
> Maybe it could benefit from a patch proposal.

That sounds a bit snarky to me... I am sorry if the last sentence came
across wrong.  Given the preceding sentences (which you did not quote),
I thought it would have been clear this is merely a related
afterthought, and not meant to disparage your work on xref in any way.
In fact, I am happy about that effort to unify and standardize commands.

You're obviously right that a concrete suggestion is more helpful.

Disclaimer: Recent discussion seems to have centered around the question
if the newly opened file buffers should be cleaned up somehow.  I am not
worried nor bothered by having all these buffers opened.  It's always
been that way in Emacs, and it's never been a problem for me.

I care more (but it's not all that important to me) about the buffers
and points *shown* in windows.  In that respect, what if
xref--marker-ring stored, together with the location where
xref-push-marker-stack is called, the window where it is called.  Then
xref-pop-marker-stack could look at the top of the stack and:
- if window is same as current: same as now, ie, goto buffer and point
  in same window
- if window is different, still there and showing the buffer of the
  stack location, switch to that window and go to location's point
- if the window no longer exists, or shows a different buffer now, use
  the current window to switch to the buffer and goto location's point

That would, I think, be quite close to going back "in time" to the
window/buffer setup that the user had before, whenever that is possible.
If that is deemed a reasonable goal, the last clause seems the only one
where the behavior could differ.  Maybe one could reuse another window
showing the target buffer, or even choose one of two or three actions,
customizable by an option.