GNU bug report logs - #7215
24.0.50; Minibuffer path completion mispositions point

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7215 in the body.
You can then email your comments to 7215 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tim Van Holder <tim.vanholder <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Minibuffer path completion mispositions point
Date: Thu, 14 Oct 2010 15:22:16 +0200

Recipe:

$ mkdir directory
$ cd directory
$ mkdir subdir
$ cd subdir
$ emacs -Q
  C-x C-f

At this point, the minibuffer will contain (with * indicating point):

  Find file: .../directory/subdir/*

Now delete most of "directory", leaving the minibuffer as:

  Find file: .../dir*/subdir/

Now press [tab]. This correctly completes "dir" back to "directory", but
also moves point backwards, resulting in:

  Find file: .../di*rectory/subdir/

The amount point moves seems to be relative to the place it should end
up at (it will always be after the "di" regardless of whether the
completion was for "di", "dir" or "direc"). It also seems to be related
to the size of the subsequent path component; doing the same tab
completion for the portion of the path before "directory" makes point
jump much further back.

For the last path component (subdir in this case) it _looks_ fine,
resulting in

  Find file: .../directory/subdir*/

But simply adding a single letter after the trailing '/' shows that this
is just the one case where it looks like it's doing the right thing;
trying to complete "subdir" from "sub" then yields:

  Find file: .../directory/subdi*r/x


In GNU Emacs 24.0.50.2 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
 of 2010-10-14 on leeloo
Windowing system distributor `The Cygwin/X Project', version 11.0.10503000
configured using `configure  '--with-x''

Message #8 received at 7215 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Tim Van Holder <tim.vanholder <at> gmail.com>
Cc: 7215 <at> debbugs.gnu.org
Subject: Re: bug#7215: 24.0.50; Minibuffer path completion mispositions point
Date: Fri, 15 Oct 2010 16:08:51 +0200

[Message part 1 (text/plain, inline)]

On Thu, 14 Oct 2010 15:22:16 +0200 Tim Van Holder <tim.vanholder <at> gmail.com> wrote:

> Recipe:
>
> $ mkdir directory
> $ cd directory
> $ mkdir subdir
> $ cd subdir
> $ emacs -Q
>   C-x C-f
>
> At this point, the minibuffer will contain (with * indicating point):
>
>   Find file: .../directory/subdir/*
>
> Now delete most of "directory", leaving the minibuffer as:
>
>   Find file: .../dir*/subdir/
>
> Now press [tab]. This correctly completes "dir" back to "directory", but
> also moves point backwards, resulting in:
>
>   Find file: .../di*rectory/subdir/
>
> The amount point moves seems to be relative to the place it should end
> up at (it will always be after the "di" regardless of whether the
> completion was for "di", "dir" or "direc"). It also seems to be related
> to the size of the subsequent path component; doing the same tab
> completion for the portion of the path before "directory" makes point
> jump much further back.
>
> For the last path component (subdir in this case) it _looks_ fine,
> resulting in
>
>   Find file: .../directory/subdir*/
>
> But simply adding a single letter after the trailing '/' shows that this
> is just the one case where it looks like it's doing the right thing;
> trying to complete "subdir" from "sub" then yields:
>
>   Find file: .../directory/subdi*r/x

The following patch appears to fix this problem (that is, it leaves
point before the `/' following the current path component; note that in
Emacs 23.1, path completion leaves point after the `/'):

[Message part 2 (text/x-patch, inline)]

*** /data/steve/bzr/emacs/trunk/lisp/minibuffer.el	2010-10-08 13:54:31.000000000 +0200
--- /data/steve/bzr/emacs/quickfixes/lisp/minibuffer.el	2010-10-15 15:46:18.000000000 +0200
***************
*** 574,580 ****
            ;; Insert in minibuffer the chars we got.
            (completion--replace beg end completion))
  	;; Move point to its completion-mandated destination.
! 	(forward-char (- comp-pos (length completion)))
  
          (if (not (or unchanged completed))
  	   ;; The case of the string changed, but that's all.  We're not sure
--- 574,580 ----
            ;; Insert in minibuffer the chars we got.
            (completion--replace beg end completion))
  	;; Move point to its completion-mandated destination.
! 	;; (forward-char (- comp-pos (length completion)))
  
          (if (not (or unchanged completed))
  	   ;; The case of the string changed, but that's all.  We're not sure

[Message part 3 (text/plain, inline)]

Clearly, the movement calculation doesn't DTRT for path completion.  I
tried the patch with other types of completion, e.g. function and
variable names, and it also seemed fine.  But the movement is obviously
intended, so there must be cases I have overlooked where it is needed;
maybe for certain completion styles?

Steve Berman

Message #11 received at 7215 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Tim Van Holder <tim.vanholder <at> gmail.com>
Cc: 7215 <at> debbugs.gnu.org
Subject: Re: bug#7215: 24.0.50; Minibuffer path completion mispositions point
Date: Sun, 17 Oct 2010 13:31:34 -0400

> Now delete most of "directory", leaving the minibuffer as:

>   Find file: .../dir*/subdir/

> Now press [tab]. This correctly completes "dir" back to "directory", but
> also moves point backwards, resulting in:

>   Find file: .../di*rectory/subdir/

I've installed the patch below into the emacs-23 branch.  This should
fix the problem.  Please confirm,


        Stefan
        
        
=== modified file 'lisp/minibuffer.el'
--- lisp/minibuffer.el	2010-10-03 19:50:14 +0000
+++ lisp/minibuffer.el	2010-10-17 17:26:12 +0000
@@ -498,10 +498,11 @@
       (setq suffix-len (1+ suffix-len)))
     (unless (zerop suffix-len)
       (setq end (- end suffix-len))
-      (setq newtext (substring newtext 0 (- suffix-len)))))
+      (setq newtext (substring newtext 0 (- suffix-len))))
   (goto-char beg)
   (insert newtext)
-  (delete-region (point) (+ (point) (- end beg))))
+    (delete-region (point) (+ (point) (- end beg)))
+    (forward-char suffix-len)))
 
 (defun completion--do-completion (&optional try-completion-function)
   "Do the completion and return a summary of what happened.

Message #14 received at 7215 <at> debbugs.gnu.org (full text, mbox):

From: Tim Van Holder <tim.vanholder <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7215 <at> debbugs.gnu.org
Subject: Re: bug#7215: 24.0.50; Minibuffer path completion mispositions point
Date: Mon, 18 Oct 2010 08:56:55 +0200

On 17 October 2010 19:31, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> I've installed the patch below into the emacs-23 branch.  This should
> fix the problem.  Please confirm,

I'm on trunk, not the emacs-23 branch.
However, I (manually) applied the same change to trunk and the problem
did indeed go away.

Does mark matter in the minibuffer? If so, perhaps it should be
forward-char-nomark?

Note: the diff you posted seems to ignore whitespace, which made it
slightly harder to twig that you were extending the let, because the
goto-char and indent didn't change their indentation.

Message #17 received at 7215 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Tim Van Holder <tim.vanholder <at> gmail.com>
Cc: 7215 <at> debbugs.gnu.org
Subject: Re: bug#7215: 24.0.50; Minibuffer path completion mispositions point
Date: Mon, 18 Oct 2010 10:24:24 -0400

>> I've installed the patch below into the emacs-23 branch.  This should
>> fix the problem.  Please confirm,

> I'm on trunk, not the emacs-23 branch.

Yes, but the bug was there as well.  It'll get merged into trunk in due time.

> However, I (manually) applied the same change to trunk and the problem
> did indeed go away.

Thank you for confirming.

> Does mark matter in the minibuffer?

Yes.

> If so, perhaps it should be forward-char-nomark?

forward-char is a low-level function which does not touch the mark.
forward-char-nomark OTOH is a command (only defined if you load
pc-select.el) which does affect the mark.  So `forward-char' is what we
want here.

> Note: the diff you posted seems to ignore whitespace, which made it
> slightly harder to twig that you were extending the let, because the
> goto-char and indent didn't change their indentation.

It's a tradeoff: OT1H you don't see that the indentation changed, but
OTOH you do see that this part of the code has not been modified.


        Stefan

Message #22 received at 7215-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Tim Van Holder <tim.vanholder <at> gmail.com>
Subject: Re: bug#7215: 24.0.50; Minibuffer path completion mispositions point
Date: Mon, 18 Oct 2010 16:03:27 -0400

>> I'm on trunk, not the emacs-23 branch.
>> However, I (manually) applied the same change to trunk and the problem
>> did indeed go away.
> Thank you for confirming.

Closing, then,


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.