* bug#11714: 24.1.50; find-file completion on a remote directory
@ 2012-06-15 7:51 Dani Moncayo
2012-06-15 9:39 ` Michael Albinus
0 siblings, 1 reply; 5+ messages in thread
From: Dani Moncayo @ 2012-06-15 7:51 UTC (permalink / raw)
To: 11714
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11714: 24.1.50; find-file completion on a remote directory
2012-06-15 7:51 bug#11714: 24.1.50; find-file completion on a remote directory Dani Moncayo
@ 2012-06-15 9:39 ` Michael Albinus
2012-06-23 3:49 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Michael Albinus @ 2012-06-15 9:39 UTC (permalink / raw)
To: Dani Moncayo; +Cc: 11714
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11714: 24.1.50; find-file completion on a remote directory
2012-06-15 9:39 ` Michael Albinus
@ 2012-06-23 3:49 ` Stefan Monnier
2012-06-23 10:25 ` Michael Albinus
0 siblings, 1 reply; 5+ messages in thread
From: Stefan Monnier @ 2012-06-23 3:49 UTC (permalink / raw)
To: Michael Albinus; +Cc: Dani Moncayo, 11714-done
>> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11714: 24.1.50; find-file completion on a remote directory
2012-06-23 3:49 ` Stefan Monnier
@ 2012-06-23 10:25 ` Michael Albinus
2012-06-23 13:58 ` Stefan Monnier
0 siblings, 1 reply; 5+ messages in thread
From: Michael Albinus @ 2012-06-23 10:25 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 11714, Dani Moncayo
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11714: 24.1.50; find-file completion on a remote directory
2012-06-23 10:25 ` Michael Albinus
@ 2012-06-23 13:58 ` Stefan Monnier
0 siblings, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2012-06-23 13:58 UTC (permalink / raw)
To: Michael Albinus; +Cc: 11714, Dani Moncayo
>> + ;; 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-06-23 13:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-15 7:51 bug#11714: 24.1.50; find-file completion on a remote directory Dani Moncayo
2012-06-15 9:39 ` Michael Albinus
2012-06-23 3:49 ` Stefan Monnier
2012-06-23 10:25 ` Michael Albinus
2012-06-23 13:58 ` Stefan Monnier
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.