GNU bug report logs - #14829
24.3; split-window-keep-point breaks shell tab completion

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14829 in the body.
You can then email your comments to 14829 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; split-window-keep-point breaks shell tab completion
Date: Mon, 8 Jul 2013 17:08:08 -0400

[Message part 1 (text/plain, inline)]

Start `emacs -Q`
(make the window full screen height, 80 columns wide)
M-x shell RET
(in the shell buffer)
$ cd /tmp
$ mkdir foo
$ cd foo
$ touch aa.txt ab.txt cc.txt dd.txt ee.txt ff.txt gg.txt hh.txt ii.txt jj.txt kk.txt ll.txt mm.txt nn.txt oo.txt pp.txt qq.txt rr.txt ss.txt tt.txt uu.txt vv.txt ww.txt xx.txt yy.txt zz.txt
$ ls -l
$ ls -l
(this is just to fill the buffer with output.  now your shell prompt
should be the last line at the bottom of the frame, if not, hit C-l a
few times until it is.)
$ cat a<TAB>

With `(setq split-window-keep-point t)` you will see the window split,
with the top window scrolled to leave point just after the `a` in the
middle of the window.  The bottom window will have the completions for
aa.txt and ab.txt

With `(setq split-window-keep-point nil)` you will not get any window
split, but point will jump someplace higher up in the window (e.g. for
me it jumps to just after the gg.txt line).


In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2)
 of 2013-06-14 on komainu, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11303000
System Description:	Ubuntu Saucy Salamander (development branch)

Configured using:
 `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
 --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LC_COLLATE: en_US.UTF-8
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Shell

Minor modes in effect:
  erc-notifications-mode: t
  delete-selection-mode: t
  icomplete-mode: t
  shell-dirtrack-mode: t
  erc-spelling-mode: t
  erc-services-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-netsplit-mode: t
  erc-menu-mode: t
  erc-list-mode: t
  erc-pcomplete-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-autojoin-mode: t
  show-paren-mode: t
  savehist-mode: t
  rcirc-track-minor-mode: t
  global-whitespace-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

[signature.asc (application/pgp-signature, attachment)]

Message #8 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: 14829 <at> debbugs.gnu.org
Date: Thu, 11 Jul 2013 15:37:43 -0400

[Message part 1 (text/plain, inline)]

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)

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Barry Warsaw <barry <at> python.org>
Cc: 14829 <at> debbugs.gnu.org
Subject: Re: bug#14829: 24.3;
 split-window-keep-point breaks shell tab completion
Date: Fri, 12 Jul 2013 10:20:22 +0200

> With `(setq split-window-keep-point t)` you will see the window split,
> with the top window scrolled to leave point just after the `a` in the
> middle of the window.  The bottom window will have the completions for
> aa.txt and ab.txt
>
> With `(setq split-window-keep-point nil)` you will not get any window
> split, but point will jump someplace higher up in the window (e.g. for
> me it jumps to just after the gg.txt line).

`split-window-below' here does

    (setq new-window (split-window nil size))
    (unless split-window-keep-point

so I don't understand how setting `split-window-keep-point' can affect
the decisison whether to split the window.

Does anyone know where this behavior comes from?

martin

Message #14 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14829 <at> debbugs.gnu.org, barry <at> python.org
Subject: Re: bug#14829: 24.3;
 split-window-keep-point breaks shell tab completion
Date: Fri, 12 Jul 2013 12:26:34 +0300

> Date: Fri, 12 Jul 2013 10:20:22 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 14829 <at> debbugs.gnu.org
> 
>  > With `(setq split-window-keep-point t)` you will see the window split,
>  > with the top window scrolled to leave point just after the `a` in the
>  > middle of the window.  The bottom window will have the completions for
>  > aa.txt and ab.txt
>  >
>  > With `(setq split-window-keep-point nil)` you will not get any window
>  > split, but point will jump someplace higher up in the window (e.g. for
>  > me it jumps to just after the gg.txt line).
> 
> `split-window-below' here does
> 
>      (setq new-window (split-window nil size))
>      (unless split-window-keep-point
> 
> so I don't understand how setting `split-window-keep-point' can affect
> the decisison whether to split the window.

Maybe it is split, and then deleted, before we have a chance of
displaying it?

Message #17 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14829 <at> debbugs.gnu.org, barry <at> python.org
Subject: Re: bug#14829: 24.3;
 split-window-keep-point breaks shell tab completion
Date: Fri, 12 Jul 2013 12:12:57 +0200

> Maybe it is split, and then deleted, before we have a chance of
> displaying it?

Maybe it is not split at all for other reasons.  But that decision
should never be affected by `split-window-keep-point'.  Barry, can you
check whether and/or why not a window splitting occurs?

martin

Message #20 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 14829 <at> debbugs.gnu.org
Subject: Re: bug#14829: 24.3; split-window-keep-point breaks shell tab
 completion
Date: Fri, 12 Jul 2013 10:12:04 -0400

[Message part 1 (text/plain, inline)]

On Jul 12, 2013, at 12:26 PM, Eli Zaretskii wrote:

>Maybe it is split, and then deleted, before we have a chance of
>displaying it?

I think that's exactly what's happening.  I did a long session of edebug
tracing and observed that behavior (split, then deleted).  I'm sorry that I
don't remember the details - it was quite a long spelunk through the Elisp.

[signature.asc (application/pgp-signature, attachment)]

Message #23 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14829 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14829: 24.3; split-window-keep-point breaks shell tab
 completion
Date: Fri, 12 Jul 2013 10:18:38 -0400

[Message part 1 (text/plain, inline)]

On Jul 12, 2013, at 12:12 PM, martin rudalics wrote:

> > Maybe it is split, and then deleted, before we have a chance of
> > displaying it?
>
>Maybe it is not split at all for other reasons.  But that decision
>should never be affected by `split-window-keep-point'.  Barry, can you
>check whether and/or why not a window splitting occurs?

With this workaround:

(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)

and the setup I mentioned earlier (e.g. shell buffer filled with output,
prompt on bottom line of window)...

If you deactivate the advice, what happens when you hit TAB is that you don't
see the split, but you also don't see the completion buffer.  Point just jumps
up to the end-of-line on a line about half-way up the window.

With the advice activated, the window gets split, with the completion buffer
on bottom, and the shell buffer scrolled up so that point remains on the
prompt line which is now approximately in the middle of its buffer (looks to
be a few lines lower, but that's really immaterial).

I notice the exact same behavior in an ERC window, so it's clearly related to
completion-at-point.  Hence the advice in the workaround.

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Barry Warsaw <barry <at> python.org>, martin rudalics <rudalics <at> gmx.at>
Cc: 14829 <at> debbugs.gnu.org
Subject: Re: bug#14829: (no subject)
Date: Mon, 22 Jul 2013 13:18:20 -0400

> 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.

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?


        Stefan

Message #29 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14829 <at> debbugs.gnu.org, Barry Warsaw <barry <at> python.org>
Subject: Re: bug#14829: (no subject)
Date: Mon, 22 Jul 2013 19:37:07 +0200

> 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.

With `inhibit-same-window' t one might want to show the same buffer in the
new window.

> 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?

It happens because \\[split-window-below] gets substituted by C-x 2.

Why not declare `split-window-keep-point' obsolete and always keep
point?

martin

Message #32 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 14829 <at> debbugs.gnu.org
Subject: Re: bug#14829: (no subject)
Date: Mon, 22 Jul 2013 13:41:10 -0400

[Message part 1 (text/plain, inline)]

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.

[signature.asc (application/pgp-signature, attachment)]

Message #35 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14829 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#14829: (no subject)
Date: Mon, 22 Jul 2013 13:42:22 -0400

[Message part 1 (text/plain, inline)]

On Jul 22, 2013, at 07:37 PM, martin rudalics wrote:

>It happens because \\[split-window-below] gets substituted by C-x 2.
>
>Why not declare `split-window-keep-point' obsolete and always keep
>point?

Please no!  C-x 2 with split-window-keep-point nil is a *really* important
feature, to me at least.

[signature.asc (application/pgp-signature, attachment)]

Message #38 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14829 <at> debbugs.gnu.org, Barry Warsaw <barry <at> python.org>
Subject: Re: bug#14829: (no subject)
Date: Mon, 22 Jul 2013 14:56:42 -0400

>> 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.
> With `inhibit-same-window' t one might want to show the same buffer in the
> new window.

I can live with that "problem".


        Stefan

Message #41 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Barry Warsaw <barry <at> python.org>
Cc: 14829 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#14829: (no subject)
Date: Tue, 23 Jul 2013 09:10:05 +0200

>> Why not declare `split-window-keep-point' obsolete and always keep
>> point?
> 
> Please no!  C-x 2 with split-window-keep-point nil is a *really* important
> feature, to me at least.

OK.  Don't worry ;-)

martin

Message #44 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14829 <at> debbugs.gnu.org, Barry Warsaw <barry <at> python.org>
Subject: Re: bug#14829: (no subject)
Date: Tue, 23 Jul 2013 09:10:25 +0200

> I can live with that "problem".

So what do we prefer?  Handle this option in `split-window-sensibly' or
in `split-window-below'?

martin

Message #47 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14829 <at> debbugs.gnu.org, Barry Warsaw <barry <at> python.org>
Subject: Re: bug#14829: (no subject)
Date: Tue, 23 Jul 2013 09:09:27 -0400

>> I can live with that "problem".
> So what do we prefer?  Handle this option in `split-window-sensibly' or
> in `split-window-below'?

I think we can start by let-binding split-window-keep-point to t in
display-buffer.


        Stefan

Message #50 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 14829 <at> debbugs.gnu.org
Subject: Re: bug#14829: (no subject)
Date: Tue, 23 Jul 2013 09:38:25 -0400

[Message part 1 (text/plain, inline)]

On Jul 23, 2013, at 09:09 AM, Stefan Monnier wrote:

>>> I can live with that "problem".
>> So what do we prefer?  Handle this option in `split-window-sensibly' or
>> in `split-window-below'?
>
>I think we can start by let-binding split-window-keep-point to t in
>display-buffer.

I'm happy to test out a patch if it can be applied to 24.3.

[signature.asc (application/pgp-signature, attachment)]

Message #53 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14829 <at> debbugs.gnu.org, Barry Warsaw <barry <at> python.org>
Subject: Re: bug#14829: (no subject)
Date: Thu, 25 Jul 2013 12:04:55 +0200

> I think we can start by let-binding split-window-keep-point to t in
> display-buffer.

Done.

martin

Message #56 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Barry Warsaw <barry <at> python.org>
Cc: 14829 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#14829: (no subject)
Date: Thu, 25 Jul 2013 12:05:09 +0200

> I'm happy to test out a patch if it can be applied to 24.3.

It's trivial, try the one below.

Thanks, martin

--- lisp/window.el	2013-07-06 14:24:54 +0000
+++ lisp/window.el	2013-07-25 09:32:11 +0000
@@ -5470,6 +5470,9 @@
   (let ((buffer (if (bufferp buffer-or-name)
 		    buffer-or-name
 		  (get-buffer buffer-or-name)))
+	;; Make sure that when we split windows the old window keeps
+	;; point, bug#14829.
+	(split-window-keep-point t)
 	;; Handle the old form of the first argument.
 	(inhibit-same-window (and action (not (listp action)))))
     (unless (listp action) (setq action nil))

Message #59 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: Barry Warsaw <barry <at> python.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14829 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#14829: (no subject)
Date: Fri, 26 Jul 2013 22:52:46 -0400

[Message part 1 (text/plain, inline)]

On Jul 25, 2013, at 12:05 PM, martin rudalics wrote:

>> I'm happy to test out a patch if it can be applied to 24.3.
>
>It's trivial, try the one below.
>
>Thanks, martin
>
>--- lisp/window.el	2013-07-06 14:24:54 +0000
>+++ lisp/window.el	2013-07-25 09:32:11 +0000
>@@ -5470,6 +5470,9 @@
>    (let ((buffer (if (bufferp buffer-or-name)
>  		    buffer-or-name
>  		  (get-buffer buffer-or-name)))
>+	;; Make sure that when we split windows the old window keeps
>+	;; point, bug#14829.
>+	(split-window-keep-point t)
>  	;; Handle the old form of the first argument.
>  	(inhibit-same-window (and action (not (listp action)))))
>      (unless (listp action) (setq action nil))

Works great, thanks.  I've applied this to Ubuntu 13.10's version of Emacs
24.3.

[signature.asc (application/pgp-signature, attachment)]

Message #62 received at 14829 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Barry Warsaw <barry <at> python.org>
Cc: 14829 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#14829: (no subject)
Date: Sat, 27 Jul 2013 10:18:49 +0200

> Works great, thanks.  I've applied this to Ubuntu 13.10's version of Emacs
> 24.3.

If you feel that no more should be done, please close this bug.

Thanks, martin

Message #67 received at 14829-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 14829-done <at> debbugs.gnu.org
Cc: Barry Warsaw <barry <at> python.org>
Subject: Re: bug#14829: (no subject)
Date: Mon, 29 Jul 2013 18:56:13 +0200

> Works great, thanks.  I've applied this to Ubuntu 13.10's version of Emacs
> 24.3.

Checked in as revision 113542.  Bug closed.

Thanks, martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.