bug#11714: 24.1.50; find-file completion on a remote directory

bug#11714: 24.1.50; find-file completion on a remote directory

[Dani Moncayo]

Recipe from "emacs -Q":
1. Eval: (cd "/some-user@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@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

bug#11714: 24.1.50; find-file completion on a remote directory

[Michael Albinus]

Dani Moncayo <dmoncayo@gmail.com> writes:

> Recipe from "emacs -Q":
> 1. Eval: (cd "/some-user@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.

bug#11714: 24.1.50; find-file completion on a remote directory

[Stefan Monnier]

>> Recipe from "emacs -Q":
>> 1. Eval: (cd "/some-user@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.

bug#11714: 24.1.50; find-file completion on a remote directory

[Michael Albinus]

Stefan Monnier <monnier@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.

bug#11714: 24.1.50; find-file completion on a remote directory

[Stefan Monnier]

>> +  ;; 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