bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[chad]

1. Run `emacs -Q'.
2. Type: `C-x 1' (make sure there is only one window)
3. Type: `C-x C-f /tm TAB'
4. Emacs creates a new window for the completions, but puts the cursor
   in the wrong window (it's back in the original window, not
   *Completions* or the minibuffer.

If the windows are already split for any reason, this bug isn't triggered.


In GNU Emacs 24.1.50.1 (x86_64-apple-darwin12.0.0, NS apple-appkit-1187.00)
 of 2012-08-13 on protip.local
Bzr revision: 109116 yandros@mit.edu-20120813173139-o4vvx2j0ino1omw9
Windowing system distributor `Apple', version 10.3.1187
Configured using:
 `configure '--with-ns''

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

Major mode: Text

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
, SPC n o t SPC t h e SPC c o m p l e t e <backspace> 
<escape> <backspace> <escape> <backspace> ( <backspace> 
* s <backspace> c o <backspace> <backspace> C o m p 
l e t e <backspace> i o n s * SPC o r SPC t h e SPC 
m i n i b u f f e r . C-x C-f M-x M-q <up> C-a SPC 
SPC SPC M-q <down> C-e <return> <return> <up> <up> 
<up> <up> <up> C-k <down> <down> <down> <return> I 
f SPC y o u SPC s p l i t SPC t h e SPC w i n d o w 
C-a C-k I f SPC t h e SPC w i n d o w s SPC a r e SPC 
a l r e a d y SPC s p l i t SPC f o r SPC a n y SPC 
r e a s o n , SPC t h i s SPC b u g SPC i s n ' t SPC 
t r i g g e r e d . <down> <down> C-k C-k C-x u C-k 
C-k C-k <wheel-down> <double-wheel-down> <triple-wheel-down> 
<triple-wheel-down> <triple-wheel-down> <wheel-up> 
<double-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
<triple-wheel-up> <triple-wheel-up> <triple-wheel-up> 
C-x C-w <escape> <backspace> <escape> <backspace> c 
o m p l e t e i <backspace> <backspace> i o n - b u 
g . e <backspace> t x t <return> <down-mouse-1> <mouse-1> 
<down-mouse-1> <mouse-1> <down-mouse-1> <mouse-1> <down-mouse-1> 
<drag-mouse-1> <down> <down> <up> C-SPC <down> <down> 
<down> <down> <down> <down> <down> <down> <escape> 
w M-x r e p o SPC r <backspace> C-x o C-x o r SPC C-x 
o e SPC SPC <return>

Recent messages:
completing-read-default: Command attempted to use minibuffer while in minibuffer
Quit
Undo!
byte-code: Beginning of buffer [20 times]
Auto-saving...
Saving file /Users/yandros/Project/emacs/completion-bug.txt...
Wrote /Users/yandros/Project/emacs/completion-bug.txt
Loading vc-git...done
Mark set [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(vc-git shadow sort gnus-util mail-extr emacsbug message format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils help-mode easymenu time-date tooltip
ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process ns multi-tty emacs)

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Mon, 13 Aug 2012 11:23:33 -0700
> 
> 1. Run `emacs -Q'.
> 2. Type: `C-x 1' (make sure there is only one window)
> 3. Type: `C-x C-f /tm TAB'
> 4. Emacs creates a new window for the completions, but puts the cursor
>    in the wrong window (it's back in the original window, not
>    *Completions* or the minibuffer.

I cannot reproduce this with the current trunk.

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[chad]

On 13 Aug 2012, at 12:16, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: chad <yandros@MIT.EDU>
>> Date: Mon, 13 Aug 2012 11:23:33 -0700
>> 
>> 1. Run `emacs -Q'.
>> 2. Type: `C-x 1' (make sure there is only one window)
>> 3. Type: `C-x C-f /tm TAB'
>> 4. Emacs creates a new window for the completions, but puts the cursor
>>   in the wrong window (it's back in the original window, not
>>   *Completions* or the minibuffer.
> 
> I cannot reproduce this with the current trunk.

I'm still seeing the problem, but my recipe was off.  Try this instead:

1. mkdir /tmp/emacsbug-foo1 /tmp/emacsbug-foo2
2. Run `emacs -Q'.
3. Type: `C-x C-f /tmp/emacsbug-foo TAB'
4. Emacs creates a new window for the completions, but puts the cursor
  in the wrong window (it's back in the original window, not
  *Completions* or the minibuffer.

It seems to be important that there is more than one completion for the current prefix string, presumably so emacs will create the *Completions* buffer. That was true on my system but probably not generally true.

With this recipe, it still happens in revno 109117.

Thank you.
*Chad

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[Daiki Ueno]

chad <yandros@MIT.EDU> writes:

> I'm still seeing the problem, but my recipe was off.  Try this instead:

I can reproduce it and find it quite annoying.  There seems to be
another couple of typo in Stefan's with-selected-window cleanup
(r109577):

> +(defun internal--after-with-seleted-window (state)
> +  ;; First reset frame-selected-window.
> +  (when (window-live-p (nth 2 state))
> +    ;; We don't use set-frame-selected-window because it does not
> +    ;; pass the `norecord' argument to Fselect_window.
> +    (select-window (nth 2 state) 'norecord)
> +    (and (frame-live-p (nth 3 state))
> +         (not (eq (tty-top-frame) (nth 3 state)))
> +         (select-frame (nth 3 state) 'norecord)))
> +  ;; Then reset the actual selected-window.
> +  (when (window-live-p (nth 2 state))
> +    (select-window (nth 2 state) 'norecord)))

The last two (nth 2 state) should be (nth 1 state).

Regards,
-- 
Daiki Ueno

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Mon, 13 Aug 2012 14:04:47 -0700
> Cc: 12193@debbugs.gnu.org
> 
> 
> On 13 Aug 2012, at 12:16, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: chad <yandros@MIT.EDU>
> >> Date: Mon, 13 Aug 2012 11:23:33 -0700
> >> 
> >> 1. Run `emacs -Q'.
> >> 2. Type: `C-x 1' (make sure there is only one window)
> >> 3. Type: `C-x C-f /tm TAB'
> >> 4. Emacs creates a new window for the completions, but puts the cursor
> >>   in the wrong window (it's back in the original window, not
> >>   *Completions* or the minibuffer.
> > 
> > I cannot reproduce this with the current trunk.
> 
> I'm still seeing the problem, but my recipe was off.  Try this instead:
> 
> 1. mkdir /tmp/emacsbug-foo1 /tmp/emacsbug-foo2
> 2. Run `emacs -Q'.
> 3. Type: `C-x C-f /tmp/emacsbug-foo TAB'
> 4. Emacs creates a new window for the completions, but puts the cursor
>   in the wrong window (it's back in the original window, not
>   *Completions* or the minibuffer.

What do you mean by "puts the cursor in the wrong window"?  When Emacs
completes, it shows the active cursor in the minibuffer, not in any
other window.

> It seems to be important that there is more than one completion for the current prefix string, presumably so emacs will create the *Completions* buffer. That was true on my system but probably not generally true.

I get the *Completions* buffer popped up, allright.  I just don't see
the cursor where I wouldn't expect it.

> With this recipe, it still happens in revno 109117.

Which is 500 revisions old.  Maybe you should resync.

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[Daiki Ueno]

Daiki Ueno <ueno@unixuser.org> writes:

> chad <yandros@MIT.EDU> writes:
>
>> I'm still seeing the problem, but my recipe was off.  Try this instead:
>
> I can reproduce it and find it quite annoying.

Sorry, I missed the revno of the report so might be a different issue -
but the symptom looks quite similar to what I experience with the
current trunk.  FWIW, my recipe is:

1. emacs -Q in Emacs source tree
2. C-x C-f config. TAB
3. the main window splitted vertically to show the completion and the
   cursor jumps to the top window from the minibuffer window.

>> +  (when (window-live-p (nth 2 state))
>> +    (select-window (nth 2 state) 'norecord)))
>
> The last two (nth 2 state) should be (nth 1 state).

By fixing these, the problem disappears.

Regards,
-- 
Daiki Ueno

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[chad]

On 13 Aug 2012, at 19:50, Eli Zaretskii <eliz@gnu.org> wrote:

>> With this recipe, it still happens in revno 109117.
> 
> Which is 500 revisions old.  Maybe you should resync.

I wonder if this is a bazaar numbering issue? My first report was from a sync that was less than an hour old; the second was less than 5 minutes old. I do have a few private patches on that branch, so maybe that's my fault?  I'm a bazaar novice.


> 1. emacs -Q in Emacs source tree
> 2. C-x C-f config. TAB
> 3. the main window splitted vertically to show the completion and the
>   cursor jumps to the top window from the minibuffer window.

Yep, this is exactly what I'm seeing, %100 reproducible.

>>> +  (when (window-live-p (nth 2 state))
>>> +    (select-window (nth 2 state) 'norecord)))
>> 
>> The last two (nth 2 state) should be (nth 1 state).
> 
> By fixing these, the problem disappears.

For me as well.  Thank you.

*Chad
P.S. I'll admit to being amused that my report mentioned that the cursor was in the wrong window, and I got the reply ``but the cursor shouldn't be in that window''. :-)

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[Chong Yidong]

Daiki Ueno <ueno@unixuser.org> writes:

> The last two (nth 2 state) should be (nth 1 state).

Thanks.  I committed the fix to the trunk on your behalf.

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Mon, 13 Aug 2012 20:29:22 -0700
> Cc: 12193@debbugs.gnu.org
> 
> On 13 Aug 2012, at 19:50, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> With this recipe, it still happens in revno 109117.
> > 
> > Which is 500 revisions old.  Maybe you should resync.
> 
> I wonder if this is a bazaar numbering issue? My first report was from a sync that was less than an hour old; the second was less than 5 minutes old. I do have a few private patches on that branch, so maybe that's my fault?  I'm a bazaar novice.

If your branch is not bound to the upstream branch, then revision
numbers are useless, because they have no relation to the trunk.  You
should then use revision-ids, not revnos.

> P.S. I'll admit to being amused that my report mentioned that the cursor was in the wrong window, and I got the reply ``but the cursor shouldn't be in that window''. :-)

I never said anything like that.

bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116

[chad]

On 14 Aug 2012, at 08:41, Eli Zaretskii <eliz@gnu.org> wrote:

> If your branch is not bound to the upstream branch, then revision
> numbers are useless, because they have no relation to the trunk.  You
> should then use revision-ids, not revnos.

Ah, that would be it.  Thank you.

>> P.S. I'll admit to being amused that my report mentioned that the cursor was in the wrong window, and I got the reply ``but the cursor shouldn't be in that window''. :-)
> 
> I never said anything like that.

Huh.  I said:

> Emacs creates a new window for the completions, but puts the cursor
>  in the wrong window (it's back in the original window, not
>  *Completions* or the minibuffer.

I.e. "the cursor is in the wrong window", and you said:

> What do you mean by "puts the cursor in the wrong window"?  When Emacs
> completes, it shows the active cursor in the minibuffer, not in any
> other window.

i.e. "it shouldn't be in that window".  Maybe I should have replied with an Andreas-style:  "Yes".

Thanks again for your help, and all the hard work on Emacs.

*Chad