* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
@ 2012-08-13 18:23 chad
2012-08-13 19:16 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: chad @ 2012-08-13 18:23 UTC (permalink / raw)
To: 12193
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-13 18:23 bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116 chad
@ 2012-08-13 19:16 ` Eli Zaretskii
2012-08-13 21:04 ` chad
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2012-08-13 19:16 UTC (permalink / raw)
To: chad; +Cc: 12193
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-13 19:16 ` Eli Zaretskii
@ 2012-08-13 21:04 ` chad
2012-08-14 2:50 ` Daiki Ueno
2012-08-14 2:50 ` Eli Zaretskii
0 siblings, 2 replies; 10+ messages in thread
From: chad @ 2012-08-13 21:04 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12193
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-13 21:04 ` chad
@ 2012-08-14 2:50 ` Daiki Ueno
2012-08-14 3:19 ` Daiki Ueno
2012-08-14 4:37 ` Chong Yidong
2012-08-14 2:50 ` Eli Zaretskii
1 sibling, 2 replies; 10+ messages in thread
From: Daiki Ueno @ 2012-08-14 2:50 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12193, chad
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-14 2:50 ` Daiki Ueno
@ 2012-08-14 3:19 ` Daiki Ueno
2012-08-14 3:29 ` chad
2012-08-14 4:37 ` Chong Yidong
1 sibling, 1 reply; 10+ messages in thread
From: Daiki Ueno @ 2012-08-14 3:19 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 12193, chad
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-14 3:19 ` Daiki Ueno
@ 2012-08-14 3:29 ` chad
2012-08-14 15:41 ` Eli Zaretskii
0 siblings, 1 reply; 10+ messages in thread
From: chad @ 2012-08-14 3:29 UTC (permalink / raw)
To: Daiki Ueno; +Cc: 12193
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''. :-)
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-14 3:29 ` chad
@ 2012-08-14 15:41 ` Eli Zaretskii
2012-08-14 15:59 ` chad
0 siblings, 1 reply; 10+ messages in thread
From: Eli Zaretskii @ 2012-08-14 15:41 UTC (permalink / raw)
To: chad; +Cc: 12193, ueno
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-14 15:41 ` Eli Zaretskii
@ 2012-08-14 15:59 ` chad
0 siblings, 0 replies; 10+ messages in thread
From: chad @ 2012-08-14 15:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 12193, ueno
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-14 2:50 ` Daiki Ueno
2012-08-14 3:19 ` Daiki Ueno
@ 2012-08-14 4:37 ` Chong Yidong
1 sibling, 0 replies; 10+ messages in thread
From: Chong Yidong @ 2012-08-14 4:37 UTC (permalink / raw)
To: Daiki Ueno; +Cc: 12193, chad
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116
2012-08-13 21:04 ` chad
2012-08-14 2:50 ` Daiki Ueno
@ 2012-08-14 2:50 ` Eli Zaretskii
1 sibling, 0 replies; 10+ messages in thread
From: Eli Zaretskii @ 2012-08-14 2:50 UTC (permalink / raw)
To: chad; +Cc: 12193
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-08-14 15:59 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-08-13 18:23 bug#12193: 24.1.50; 24.1.50; Completion broken in revno 109116 chad
2012-08-13 19:16 ` Eli Zaretskii
2012-08-13 21:04 ` chad
2012-08-14 2:50 ` Daiki Ueno
2012-08-14 3:19 ` Daiki Ueno
2012-08-14 3:29 ` chad
2012-08-14 15:41 ` Eli Zaretskii
2012-08-14 15:59 ` chad
2012-08-14 4:37 ` Chong Yidong
2012-08-14 2:50 ` Eli Zaretskii
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).