GNU bug report logs - #11714
24.1.50; find-file completion on a remote directory

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 11714 in the body.
You can then email your comments to 11714 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: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.1.50; find-file completion on a remote directory
Date: Fri, 15 Jun 2012 09:51:59 +0200

Recipe from "emacs -Q":
1. Eval: (cd "/some-user <at> some-host:~")
2. Give the correct password.
3. Type: C-x C-f / h o m e / s o m e - u s e r / t TAB

After doing that, I get the error message:
  Assertion failed: (equal (funcall unquote qstring) completion)

In the *Messages* buffer the message has more info:
  completion--twq-try: Assertion failed: (equal (funcall unquote
qstring) completion)

[I'm using the "pscp" Tramp method.]

In GNU Emacs 24.1.50.1 (i386-mingw-nt6.1.7601)
 of 2012-06-14 on DANI-PC
Bzr revision: 108603 rgm <at> gnu.org-20120613181105-t7txabt3lyx44f60
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -I../../libs/giflib-4.1.4-1/include
 -I../../emacs/libs/gnutls-3.0.16/include -I../../libs/jpeg-6b-4/include
 -I../../libs/libpng-1.4.10 -I../../libs/libxpm-3.5.8/include
 -I../../libs/libxpm-3.5.8/src -I../../libs/tiff-3.8.2-1/include
 -I../../libs/zlib-1.2.6'



-- 
Dani Moncayo

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 11714 <at> debbugs.gnu.org
Subject: Re: bug#11714: 24.1.50; find-file completion on a remote directory
Date: Fri, 15 Jun 2012 11:39:42 +0200

Dani Moncayo <dmoncayo <at> gmail.com> writes:

> Recipe from "emacs -Q":
> 1. Eval: (cd "/some-user <at> some-host:~")
> 2. Give the correct password.
> 3. Type: C-x C-f / h o m e / s o m e - u s e r / t TAB
>
> After doing that, I get the error message:
>   Assertion failed: (equal (funcall unquote qstring) completion)

This is the same problem as #11628. Unfortunately, I have no clue how to
fix it.

Stefan?

Best regards, Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 11714-done <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#11714: 24.1.50; find-file completion on a remote directory
Date: Fri, 22 Jun 2012 23:49:46 -0400

>> Recipe from "emacs -Q":
>> 1. Eval: (cd "/some-user <at> some-host:~")
>> 2. Give the correct password.
>> 3. Type: C-x C-f / h o m e / s o m e - u s e r / t TAB

I just fixed this in the trunk with the patch below.


        Stefan


=== modified file 'lisp/minibuffer.el'
--- lisp/minibuffer.el  2012-06-18 20:39:52 +0000
+++ lisp/minibuffer.el  2012-06-23 03:46:25 +0000
@@ -488,7 +488,7 @@
 
 (defun completion--twq-try (string ustring completion point
                                    unquote requote)
-  ;; Basically two case: either the new result is
+  ;; Basically two cases: either the new result is
   ;; - commonprefix1 <point> morecommonprefix <qpos> suffix
   ;; - commonprefix <qpos> newprefix <point> suffix
   (pcase-let*
@@ -505,8 +505,13 @@
          ((> point (length prefix)) (+ qpos (length qstr1)))
          (t (car (funcall requote point string))))))
     ;; Make sure `requote' worked.
-    (assert (equal (funcall unquote qstring) completion))
-    (cons qstring qpoint)))
+    (if (equal (funcall unquote qstring) completion)
+       (cons qstring qpoint)
+      ;; If requote failed (e.g. because sifn-requote did not handle
+      ;; Tramp's "/foo:/bar//baz -> /foo:/baz" truncation), then at least
+      ;; try requote properly.
+      (let ((qstr (funcall qfun completion)))
+       (cons qstr (length qstr))))))
 
 (defun completion--string-equal-p (s1 s2)
   (eq t (compare-strings s1 nil nil s2 nil nil 'ignore-case)))
@@ -2130,6 +2135,12 @@
   ;; find the position corresponding to UPOS in QSTR, but
   ;; substitute-in-file-name can do anything, depending on file-name-handlers.
   ;; Kind of like in rfn-eshadow-update-overlay, only worse.
+  ;; FIXME: example of thing we do not handle: Tramp's makes
+  ;; (substitute-in-file-name "/foo:~/bar//baz") -> "/scpc:foo:/baz".
+  ;; FIXME: One way to try and handle "all" cases is to require
+  ;; substitute-in-file-name to preserve text-properties, so we could
+  ;; apply text-properties to the input string and then look for them in
+  ;; the output to understand what comes from where.
   (let ((qpos 0))
     ;; Handle substitute-in-file-name's truncation behavior.
     (let (tpos)
@@ -2824,14 +2835,14 @@
 
 (defun completion--sreverse (str)
   "Like `reverse' but for a string STR rather than a list."
-  (apply 'string (nreverse (mapcar 'identity str))))
+  (apply #'string (nreverse (mapcar 'identity str))))
 
 (defun completion--common-suffix (strs)
   "Return the common suffix of the strings STRS."
   (completion--sreverse
    (try-completion
     ""
-    (mapcar 'completion--sreverse strs))))
+    (mapcar #'completion--sreverse strs))))
 
 (defun completion-pcm--merge-completions (strs pattern)
   "Extract the commonality in STRS, with the help of PATTERN.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 11714 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#11714: 24.1.50; find-file completion on a remote directory
Date: Sat, 23 Jun 2012 12:25:42 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> I just fixed this in the trunk with the patch below.

That works, thanks!

> +  ;; FIXME: example of thing we do not handle: Tramp's makes
> +  ;; (substitute-in-file-name "/foo:~/bar//baz") -> "/scpc:foo:/baz".
> +  ;; FIXME: One way to try and handle "all" cases is to require
> +  ;; substitute-in-file-name to preserve text-properties, so we could
> +  ;; apply text-properties to the input string and then look for them in
> +  ;; the output to understand what comes from where.

Shall I do action on Tramp? If yes, could this requirement to file name
handlers be documented?

>         Stefan

Best regards, Michael.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 11714 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#11714: 24.1.50; find-file completion on a remote directory
Date: Sat, 23 Jun 2012 09:58:18 -0400

>> +  ;; FIXME: example of thing we do not handle: Tramp's makes
>> +  ;; (substitute-in-file-name "/foo:~/bar//baz") -> "/scpc:foo:/baz".
>> +  ;; FIXME: One way to try and handle "all" cases is to require
>> +  ;; substitute-in-file-name to preserve text-properties, so we could
>> +  ;; apply text-properties to the input string and then look for them in
>> +  ;; the output to understand what comes from where.
> Shall I do action on Tramp? If yes, could this requirement to file name
> handlers be documented?

No, we'd probably have to add a new file-name operation for that, or
change the requirements of substitute-in-file-name as suggested.
But if that will happen, it won't be before the next round of
completion changes.


        Stefan

Previous Next

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