On Jul 22, 2013, at 01:18 PM, Stefan Monnier wrote:

>> This fixes it for me.
>> ;; Work around a bug in split-window-keep-point and completion.
>> (defadvice completion-at-point (around completion-at-point-around)
>>   "Point safe completion"
>>   (let ((split-window-keep-point t))
>>     ad-do-it))
>> (ad-activate 'completion-at-point)
>
>Hmm... looking at it further I see that:
>- split-window-keep-point defaults to t.
>- the problem could affect other cases than completion.
>Basically, I'm leaning towards forcing split-window-keep-point to t in
>display-buffer, since AFAICT a value of nil only makes sense when you
>split a window into two so that they both show the same buffer, whereas
>in the case of display-buffer, you always want the current buffer's
>point to stay put.

This seems reasonable to me, as long as it doesn't affect C-x 2.

>Why do you (and other people) set split-window-keep-point to nil?
>What is the expected behavior from it?
>
>The docstring seems to indicate it's only meant to affect C-x 2 rather
>than all cases where we create a new window.  Martin?

C-x 2 is the only reason I set it to nil.  There used to be an old XEmacs hack
(might have been some of my personal elisp) that did what I think was called
"slow-splitting" although it was not actually slow.  It did exactly what C-x 2
with s-w-k-p set to nil does.  I love this for tall windows since in most
cases, nothing changes except you get a modeline in the middle of the window
where the split occurs.

So I'm all in favor of keeping the behavior for C-x 2 and inhibiting it for
all other purposes.  I have definitely encountered other situations that the
defadvice above does not handle.  One example is pdb-track in python-mode.
When you hit the breakpoint, the shell buffer is split with the code shown
below, but the split does not happen correct.  Point is left at the same bogus
place as described in the original bug report.