From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lukasz Pawelczyk Newsgroups: gmane.emacs.bugs Subject: bug#16909: 24.3; scrolling *Completions* window with tab sometimes chooses a wrong window Date: Wed, 5 Mar 2014 10:48:40 +0100 Message-ID: References: <5310D459.8040504@gmx.at> <6F4BAAB3-A0AD-4AE5-BD18-BE9CE1A97B77@gmail.com> <5311CA73.2030709@gmx.at> <53123279.6070203@gmx.at> <5316D1BC.3000804@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d04426adcecc75004f3d8ec28 X-Trace: ger.gmane.org 1394012948 1138 80.91.229.3 (5 Mar 2014 09:49:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Mar 2014 09:49:08 +0000 (UTC) Cc: "16909@debbugs.gnu.org" <16909@debbugs.gnu.org> To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 05 10:49:16 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WL8Rw-0003Ow-04 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Mar 2014 10:49:16 +0100 Original-Received: from localhost ([::1]:50967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL8Rv-0003Us-G4 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Mar 2014 04:49:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL8Rn-0003Un-Ss for bug-gnu-emacs@gnu.org; Wed, 05 Mar 2014 04:49:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WL8Rj-00006t-37 for bug-gnu-emacs@gnu.org; Wed, 05 Mar 2014 04:49:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WL8Ri-00006m-UM for bug-gnu-emacs@gnu.org; Wed, 05 Mar 2014 04:49:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WL8Ri-0006hd-Ep for bug-gnu-emacs@gnu.org; Wed, 05 Mar 2014 04:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Lukasz Pawelczyk Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Mar 2014 09:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16909 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16909-submit@debbugs.gnu.org id=B16909.139401292525735 (code B ref 16909); Wed, 05 Mar 2014 09:49:02 +0000 Original-Received: (at 16909) by debbugs.gnu.org; 5 Mar 2014 09:48:45 +0000 Original-Received: from localhost ([127.0.0.1]:51063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WL8RQ-0006gy-6q for submit@debbugs.gnu.org; Wed, 05 Mar 2014 04:48:45 -0500 Original-Received: from mail-ob0-f181.google.com ([209.85.214.181]:34628) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WL8RN-0006gp-2V for 16909@debbugs.gnu.org; Wed, 05 Mar 2014 04:48:41 -0500 Original-Received: by mail-ob0-f181.google.com with SMTP id wp4so755889obc.40 for <16909@debbugs.gnu.org>; Wed, 05 Mar 2014 01:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lv1UyQRfLiJdFvLlB+XbiQIeklSFOdj5tFiKwCNT16s=; b=EteXJ7CC1d/b7iC1j+BCrF4CfWhTa9TDxb3ms0IassALF/yrCW/IIcAJV52Q1buAhG R4HarL/6NvMcj6of1vHMg5QSvnrmYz6U1jihR+kJj0nPb9m82HYgkQYIobReX6sxJmBk lGKwQODqawrQDF3wg7fjMTSPBU7aKJfJWGi2wwtyIF7Ts3fNgMtZC3yY9S3m4MPJ83a2 5wtdy5fP3epiXGoSxRBYeNdPTr6rG30h/gT1MPoL9avIUoqzuVmiQjje5C5MSMJJbRvT 660xB46mnNwt9c4W7n/ckt3X2cdr27jx+C1ZUpWLxBfl/pKaXYotNbJzzSIiNDA4hjkU rjYA== X-Received: by 10.182.180.7 with SMTP id dk7mr4034629obc.20.1394012920266; Wed, 05 Mar 2014 01:48:40 -0800 (PST) Original-Received: by 10.76.3.167 with HTTP; Wed, 5 Mar 2014 01:48:40 -0800 (PST) In-Reply-To: <5316D1BC.3000804@gmx.at> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:86569 Archived-At: --f46d04426adcecc75004f3d8ec28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 5, 2014 at 8:26 AM, martin rudalics wrote: > >> We have to detect the moment when the window is closed automatically > >> anyway. At that time we can either kill the buffer or reset > >> `other-window-scroll-buffer=E2=80=99. > > > > I=E2=80=99m still not sure that even using this variable is a wise idea= . It > might be used > > by a user to configure his things. > > By design it's a plain variable and not a user option. In that case it's ok. > > A simple custom function that will always scroll > > *Completions* window seems like a better choice. You can always scroll > > by buffer name. No need to force the usage of scroll-other-window > function. > > IIRC the initial intention was to make the *Completions* window the > `next-window' so it would get scrolled automatically by C-M-v. When > that failed, `other-window-scroll-buffer' was invented to handle the > case where the *Completions* window was not the next window. I doubt > that a custom function would gain anything in this regard - it would > still have to find the window to scroll and detect when it's no more > needed. > If that's the case, sure. > I meant that if you only kill the buffer (after we used autocomplete) and > > then user will scroll-other-window (for whatever reason) it won=E2=80= =99t behave > as > > if its value is nil. We=E2=80=99d have to make it nil as well (as you m= entioned > now). > > Why? If `other-window-scroll-buffer' denotes a dead buffer, it now > should be tantamount to nil. Or am I missing something? If the 'other-window-scroll-buffer' is pointing to a dead buffer 'scroll-other-window' does not fallback to its normal behaviour. You get an 'invalid buffer' message. So we don't have to kill the *Completions* buffer. We need to set the variable back to nil to resume normal user operations after using auto complete scrolling= . > If I had an idea where to start I would have sent a patch instead of > reporting a bug :-/ > > I thought you had because you earlier said that > > All of this happens because a window that's chosen for displaying a > window > for completion is created with 'display-buffer', while the window that > is > scrolled with TAB during completion is choosen with a 'other-window' > ('scroll-other-window') function. And as shown here those windows are > not > always the same. > > which gave me the impression that you already did some preliminary > investigative work. My investigation was to figure out what is going on, not precisely where to fix it and was based on semantic's autocomplete which behaves exactly the same. I just thought that reporting this in base emacs functionality might get a higher chance to get attention. And the mechanism and a cause seems to be exactly the same. I didn't manage to pinpoint where it happens in case of elisp auto complete= . Only for semantic displayor one (which needs fixing as well). --=20 Regards Havner --f46d04426adcecc75004f3d8ec28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 5, 2014 at 8:26 AM, martin rudalics <rudalics@gmx.at> wrote:
>> We have to detect t= he moment when the window is closed automatically
>> anyway. =C2=A0At that time we can either kill the buffer or reset<= br> >> `other-window-scroll-buffer=E2=80=99.
>
> I=E2=80=99m still not sure that even using this variable is a wise ide= a. It might be used
> by a user to configure his things.

By design it's a plain variable and not a user option.

In that case it's ok.

=C2=A0
> A simple custom function that will always scroll
> *Completions* window seems like a better choice. You can always scroll=
> by buffer name. No need to force the usage of scroll-other-window func= tion.

IIRC the initial intention was to make the *Completions* window the
`next-window' so it would get scrolled automatically by C-M-v. =C2=A0Wh= en
that failed, `other-window-scroll-buffer' was invented to handle the case where the *Completions* window was not the next window. =C2=A0I doubt<= br> that a custom function would gain anything in this regard - it would
still have to find the window to scroll and detect when it's no more needed.

If that's the case, sure.


> I meant that if you only kill the buffer (after we used autocomplete) = and
> then user will scroll-other-window (for whatever reason) it won=E2=80= =99t behave as
> if its value is nil. We=E2=80=99d have to make it nil as well (as you = mentioned now).

Why? =C2=A0If `other-window-scroll-buffer' denotes a dead buffer, it no= w
should be tantamount to nil. =C2=A0Or am I missing something?
<= div>
If the 'other-window-scroll-buffer' is pointing = to a dead buffer 'scroll-other-window'
does not fallback = to its normal behaviour. You get an 'invalid buffer' message.
So we don't have to kill the *Completions* buffer. We need t= o set the variable back
to nil to resume normal user operations a= fter using auto complete scrolling.


> If I had an idea where to start I would have sent a patch instead of r= eporting a bug :-/

I thought you had because you earlier said that

=C2=A0 =C2=A0All of this happens because a window that's chosen for dis= playing a window
=C2=A0 =C2=A0for completion is created with 'display-buffer', while= the window that is
=C2=A0 =C2=A0scrolled with TAB during completion is choosen with a 'oth= er-window'
=C2=A0 =C2=A0('scroll-other-window') function. And as shown here th= ose windows are not
=C2=A0 =C2=A0always the same.

which gave me the impression that you already did some preliminary
investigative work.

My investigation was to= figure out what is going on, not precisely where to fix it and was
based on semantic's autocomplete which behaves exactly the same. I j= ust thought
that reporting this in base emacs functionality might get a higher cha= nce to get
attention. And the mechanism and a cause seems to be e= xactly the same.
I didn't manage to pinpoint where it happens= in case of elisp auto complete.
Only for semantic displayor one (which needs fixing as well).
=C2=A0

--
Regards
Havner
--f46d04426adcecc75004f3d8ec28--