bug#5030: 23.1.50; Unexpected minibuffer tab completion behavior

bug#5030: 23.1.50; Unexpected minibuffer tab completion behavior

[Matthew Dempsky]

Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

On my computer, I have only two files in my home directory beginning
with the letter 'a': ~/aaa and ~/aab.  After starting Emacs with "Emacs
-Q" and pressing "C-x C-k C-a C-k ~ / <tab> <tab>", a new window appears
to display the *Completion* buffer with all of the files in my home
directory.  I expect this.

After additionally pressing "a <tab>", the minibuffer completes to
"~/aa", and the window that previously displayed the *Completion* buffer
now switches to displaying the *Messages* buffer instead.  I don't
expect this.

Instead, I expect either for that window to continue showing the
*Completion* buffer (refreshed to display just the "aaa" and "aab"
entries) or for that window to be deleted.  (I'd prefer the former
behavior.)

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/Volumes/Disk Image/emacs-build/obj/nextstep/Emacs.app/Contents/Resources/etc/DEBUG.


In GNU Emacs 23.1.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
 of 2009-11-23 on admins-macbook-pro-2.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns' '--without-x''

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

Major mode: Lisp Interaction

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

Recent input:
C-x C-f C-a C-k ~ / <tab> <tab> a <tab> C-g M-x r e
p o r t - e m a c s - b u g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Quit

Load-path shadows:
None found.

Features:
(shadow mail-extr message ecomplete rfc822 mml mml-sec password-cache
mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231 rfc2047 rfc2045
qp ietf-drums mailabbrev nnheader gnus-util netrc time-date mm-util
mail-prsvr gmm-utils wid-edit mailheader canlock sha1 hex-util hashcash
mail-utils emacsbug sendmail regexp-opt help-mode view tooltip
ediff-hook vc-hooks lisp-float-type mwheel ns-win easymenu tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mldrag 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 loaddefs button minibuffer faces
cus-face text-properties overlay md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process ns
multi-tty emacs)

bug#5036: 23.1.50; Unexpected minibuffer tab completion behavior

[Matthew Dempsky]

It seems like the unexpected buffer switching is because the
'dedicated' flag on the temporary window created for *Completions* is
getting cleared by set-window-buffer.

My understanding of the situation so far is:

  - The `(with-output-to-temp-buffer "*Completions*" ...)' form in
minibuffer-completion-help results in `display-buffer' being called
with `display-buffer-mark-dedicated' bound to `soft'.
  - The `(and pop-up-windows ...)' clause of `display-buffer' is
evaluated*, and calls `(set-window-dedicated-p window-to-use 'soft)'.
  - However, the `window--display-buffer-2' call then calls
`set-window-buffer', which sets `w->dedicated = Qnil'.
  - Later, when `(bury-buffer)' is called to hide the minibuffer help,
it sees the window is not dedicated, so it switches to a new buffer
instead of killing the window.

(* I haven't bothered yet to look into why that particular clause is
evaluated, but I don't think it matters; it's just the one that
stepping through the code took me to.)

bug#5030: 23.1.50; Unexpected minibuffer tab completion behavior

[Matthew Dempsky]

It seems like the unexpected buffer switching is because the
'dedicated' flag on the temporary window created for *Completions* is
getting cleared by set-window-buffer.

My understanding of the situation so far is:

 - The `(with-output-to-temp-buffer "*Completions*" ...)' form in
minibuffer-completion-help results in `display-buffer' being called
with `display-buffer-mark-dedicated' bound to `soft'.
 - The `(and pop-up-windows ...)' clause of `display-buffer' is
evaluated*, and calls `(set-window-dedicated-p window-to-use 'soft)'.
 - However, the `window--display-buffer-2' call then calls
`set-window-buffer', which sets `w->dedicated = Qnil'.
 - Later, when `(bury-buffer)' is called to hide the minibuffer help,
it sees the window is not dedicated, so it switches to a new buffer
instead of killing the window.

(* I haven't bothered yet to look into why that particular clause is
evaluated, but I don't think it matters; it's just the one that
stepping through the code took me to.)

bug#5030: 23.1.50; Unexpected minibuffer tab completion behavior

[Matthew Dempsky]

On Tue, Nov 24, 2009 at 5:09 PM, Matthew Dempsky wrote:
>  - The `(and pop-up-windows ...)' clause of `display-buffer' is
> evaluated*, and calls `(set-window-dedicated-p window-to-use 'soft)'.
>  - However, the `window--display-buffer-2' call then calls
> `set-window-buffer', which sets `w->dedicated = Qnil'.

Not sure if this is the best fix, but the patch below at least
corrects this issue.  It changes `display-buffer' so that
`set-window-dedicated-p' is called after `window--display-buffer-2' in
both clauses that use `display-buffer-mark-dedicated'.

--- a/lisp/window.el
+++ b/lisp/window.el
@@ -1139,9 +1139,9 @@ consider all visible or iconified frames."
      ((or use-pop-up-frames (not frame-to-use))
       ;; We want or need a new frame.
       (let ((win (frame-selected-window (funcall pop-up-frame-function))))
-        (when display-buffer-mark-dedicated
-          (set-window-dedicated-p win display-buffer-mark-dedicated))
-        (window--display-buffer-2 buffer win)))
+	(prog1 (window--display-buffer-2 buffer win)
+	  (when display-buffer-mark-dedicated
+	    (set-window-dedicated-p win display-buffer-mark-dedicated)))))
      ((and pop-up-windows
 	   ;; Make a new window.
 	   (or (not (frame-parameter frame-to-use 'unsplittable))
@@ -1157,9 +1157,9 @@ consider all visible or iconified frames."
 		      (get-largest-window frame-to-use t))
 		     (window--try-to-split-window
 		      (get-lru-window frame-to-use t)))))
-      (when display-buffer-mark-dedicated
-        (set-window-dedicated-p window-to-use display-buffer-mark-dedicated))
-      (window--display-buffer-2 buffer window-to-use))
+      (prog1 (window--display-buffer-2 buffer window-to-use)
+	(when display-buffer-mark-dedicated
+	  (set-window-dedicated-p window-to-use display-buffer-mark-dedicated))))
      ((let ((window-to-undedicate
 	     ;; When NOT-THIS-WINDOW is non-nil, temporarily dedicate
 	     ;; the selected window to its buffer, to avoid that some of

bug#5036: marked as done (23.1.50; Unexpected minibuffer tab completion behavior)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

Your message dated Tue, 24 Nov 2009 17:50:39 -0800
with message-id <d791b8790911241750h74ba8a83g50004f2700075f0c@mail.gmail.com>
and subject line Bad bug
has caused the Emacs bug report #5036,
regarding 23.1.50; Unexpected minibuffer tab completion behavior
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)


-- 
5036: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=5036
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 3094 bytes --]

From: Matthew Dempsky <matthew@dempsky.org>
To: emacs-pretest-bug@gnu.org
Subject: Re: 23.1.50; Unexpected minibuffer tab completion behavior
Date: Tue, 24 Nov 2009 17:08:29 -0800
Message-ID: <d791b8790911241708i4d7d206dv1675ee893af0eeb5@mail.gmail.com>

It seems like the unexpected buffer switching is because the
'dedicated' flag on the temporary window created for *Completions* is
getting cleared by set-window-buffer.

My understanding of the situation so far is:

  - The `(with-output-to-temp-buffer "*Completions*" ...)' form in
minibuffer-completion-help results in `display-buffer' being called
with `display-buffer-mark-dedicated' bound to `soft'.
  - The `(and pop-up-windows ...)' clause of `display-buffer' is
evaluated*, and calls `(set-window-dedicated-p window-to-use 'soft)'.
  - However, the `window--display-buffer-2' call then calls
`set-window-buffer', which sets `w->dedicated = Qnil'.
  - Later, when `(bury-buffer)' is called to hide the minibuffer help,
it sees the window is not dedicated, so it switches to a new buffer
instead of killing the window.

(* I haven't bothered yet to look into why that particular clause is
evaluated, but I don't think it matters; it's just the one that
stepping through the code took me to.)


[-- Attachment #3: Type: message/rfc822, Size: 1255 bytes --]

From: Matthew Dempsky <matthew@dempsky.org>
To: 5036-done@emacsbugs.donarmstrong.com
Subject: Bad bug
Date: Tue, 24 Nov 2009 17:50:39 -0800
Message-ID: <d791b8790911241750h74ba8a83g50004f2700075f0c@mail.gmail.com>

Sorry, this message was meant to be added as a comment to #5030 instead.

bug#5030: 23.1.50; Unexpected minibuffer tab completion behavior

[Matthew Dempsky]

On Mon, Nov 23, 2009 at 10:09 PM, Matthew Dempsky wrote:
> Instead, I expect either for that window to continue showing the
> *Completion* buffer (refreshed to display just the "aaa" and "aab"
> entries) or for that window to be deleted.  (I'd prefer the former
> behavior.)

The last patch I posted achieves the latter behavior.  Combining with
the (proof-of-concept) patch below, I seem to achieve the former
(personally more desirable) behavior.

--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -489,10 +489,11 @@ E = after completion we now have an Exact match.
 					minibuffer-completion-table
 					minibuffer-completion-predicate)))
             (if completed
-                ;; We could also decide to refresh the completions,
-                ;; if they're displayed (and assuming there are
-                ;; completions left).
-                (minibuffer-hide-completions)
+		(cond
+		 (exact (minibuffer-hide-completions))
+		 ((get-buffer-window "*Completions*" 0)
+		  (minibuffer-completion-help))
+		 (t t))
               ;; Show the completion table, if requested.
               (cond
                ((not exact)

bug#5030: 23.1.50; Unexpected minibuffer tab completion behavior

[Matthew Dempsky]

On Tue, Nov 24, 2009 at 6:24 PM, Matthew Dempsky wrote:
> The last patch I posted achieves the latter behavior.  Combining with
> the (proof-of-concept) patch below, I seem to achieve the former
> (personally more desirable) behavior.

I think the patch below is better yet.  The second hunk fixes a bug
where `minibuffer-completion-help' assumes that it can directly
compare the input string against the list of candidate completion
strings (e.g., for `find-file', `string' will be bound to something
like `/path/to/a' while `completions' will be a list of file names
like ("aaa" "aab" . 10)).

The first hunk then improves on my last patch's behavior by if you
complete "x" to "xy" when there's also "xyz" available and the
*Completions* buffer is visible, it leaves it visible rather than
hiding it just because "xy" is now an exact match.  (I'm still playing
around with this to see how it actually feels.)

--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -489,10 +489,8 @@ E = after completion we now have an Exact match.
 					minibuffer-completion-table
 					minibuffer-completion-predicate)))
             (if completed
-                ;; We could also decide to refresh the completions,
-                ;; if they're displayed (and assuming there are
-                ;; completions left).
-                (minibuffer-hide-completions)
+		(when (get-buffer-window "*Completions*" 0)
+		  (minibuffer-completion-help))
               ;; Show the completion table, if requested.
               (cond
                ((not exact)
@@ -1003,7 +1001,9 @@ variables.")
     (message nil)
     (if (and completions
              (or (consp (cdr completions))
-                 (not (equal (car completions) string))))
+                 (not (test-completion completion
+				       minibuffer-completion-table
+				       minibuffer-completion-predicate))))
         (let* ((last (last completions))
                (base-size (cdr last))
                ;; If the *Completions* buffer is shown in a new

bug#5030: 23.1.50; Unexpected minibuffer tab completion behavior

[Stefan Monnier]

>>  - The `(and pop-up-windows ...)' clause of `display-buffer' is
>> evaluated*, and calls `(set-window-dedicated-p window-to-use 'soft)'.
>>  - However, the `window--display-buffer-2' call then calls
>> `set-window-buffer', which sets `w->dedicated = Qnil'.

> Not sure if this is the best fix, but the patch below at least
> corrects this issue.  It changes `display-buffer' so that
> `set-window-dedicated-p' is called after `window--display-buffer-2' in
> both clauses that use `display-buffer-mark-dedicated'.

Thanks for tracking that down.  I've installed a slightly different
patch which seems to fix it,


        Stefan