bug#20206: 25.0.50; [PATCH] keep diff-mode's window visible when we visit sources from diff-mode

[martin rudalics]

> I'm not sure what you mean: '((inhibit-same-window . t)) is not a valid
> as an action argument to display-buffer,

Sorry, I meant '(nil (inhibit-same-window . t)).

> and emacs barfs if I try to use
> it as such. I'm not at all married to using display-buffer-pop-up-window
> here. If you have a better idea for solving 19901 (or if you think
> there's nothing to fix), then I'm fine with it.

I'm afraid we are miscommunicating or I am misssing something.  You
propose the following change:

-  (pop-to-buffer (current-buffer))
+  (pop-to-buffer (current-buffer) '(display-buffer-use-some-window 
(inhibit-same-window . t)))

I think this precludes the following scenario: Consider a frame that
contains two windows.  The user has set `split-height-threshold' and/or
`split-width-threshold' to very small values which easily allow further
splitting.  In this case, a `pop-to-buffer' call for a buffer that
doesn't appear on the frame yet will usually try to split one of the two
windows and show the buffer in a third one.  Agreed?

Now with your proposed change `pop-to-buffer' will always use the "other
window" for displaying the current buffer, thus overriding the user's
customizations of `split-height-threshold' and `split-width-threshold'.
The reason is that `display-buffer-pop-up-window' will not be called
because `display-buffer-use-some-window' is always called first.  Do you
agree?  And can we agree that such behavior would be wrong?

Also, a user who wants to show the buffer in a separate frame via say

(setq pop-up-frames t)

will be disappointed as well.  With a two windows frame he'll never get
a new frame.  Agreed?

Maybe

(pop-to-buffer (current-buffer) t)

is already what we want here because we know that the current buffer is
not shown in the selected window.  Otherwise we could try a patch like
the one I attached.  Then we could do ...

(pop-to-buffer (current-buffer) '(nil (previous-window)))

... if I got it right this time.  WDYT?

> Another wrinkle is that the behavior reported in 19901 as a bug is only
> observable with particular geometries of the emacs X11 window. On my
> machine, 19901 is reproducible if emacs takes up my whole screen
> (1440x1050), but not if it takes only half (720x1050). Presumably emacs
> thinks that splitting into a 3rd window will create new windows that are
> too narrow. That is all to say that maybe 19901 is not a bug.

I have no problems with Bug#19901.  Let's care only about Bug#20206
here.

martin

window.el.diff
Description: Text document