From: Barry Warsaw <barry@python.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 14829@debbugs.gnu.org
Subject: bug#14829: 24.3; split-window-keep-point breaks shell tab completion
Date: Fri, 12 Jul 2013 10:18:38 -0400 [thread overview]
Message-ID: <20130712101838.21d21cd3@anarchist> (raw)
In-Reply-To: <51DFD6A9.9020901@gmx.at>
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-07-12 14:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-08 21:08 bug#14829: 24.3; split-window-keep-point breaks shell tab completion Barry Warsaw
2013-07-11 19:37 ` bug#14829: (no subject) Barry Warsaw
2013-07-22 17:18 ` Stefan Monnier
2013-07-22 17:37 ` martin rudalics
2013-07-22 17:42 ` Barry Warsaw
2013-07-23 7:10 ` martin rudalics
2013-07-22 18:56 ` Stefan Monnier
2013-07-23 7:10 ` martin rudalics
2013-07-23 13:09 ` Stefan Monnier
2013-07-23 13:38 ` Barry Warsaw
2013-07-25 10:05 ` martin rudalics
2013-07-27 2:52 ` Barry Warsaw
2013-07-27 8:18 ` martin rudalics
2013-07-29 16:56 ` martin rudalics
2013-07-25 10:04 ` martin rudalics
2013-07-22 17:41 ` Barry Warsaw
2013-07-12 8:20 ` bug#14829: 24.3; split-window-keep-point breaks shell tab completion martin rudalics
2013-07-12 9:26 ` Eli Zaretskii
2013-07-12 10:12 ` martin rudalics
2013-07-12 14:18 ` Barry Warsaw [this message]
2013-07-12 14:12 ` Barry Warsaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130712101838.21d21cd3@anarchist \
--to=barry@python.org \
--cc=14829@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).