From: Stephen Berman <stephen.berman@gmx.net>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 15419@debbugs.gnu.org
Subject: bug#15419: 24.3.50; file name as directory completion problem
Date: Sat, 10 May 2014 23:24:57 +0200 [thread overview]
Message-ID: <87a9apgwd2.fsf@rosalinde.fritz.box> (raw)
In-Reply-To: <87siokias0.fsf@rosalinde.fritz.box> (Stephen Berman's message of "Thu, 08 May 2014 16:51:27 +0200")
On Thu, 08 May 2014 16:51:27 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:
> On Wed, 07 May 2014 20:53:36 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>>> ! ;; If we're using the substring style for file name completion
>>> ! ;; and completing a directory name, this ends up tacking "/"
>>> ! ;; onto the name, resulting in "//" if the suffix begins with
>>> ! ;; "/". So drop one "/" (bug#15419).
>>> ! (cons (replace-regexp-in-string "//" "/" (concat prefix merged suffix))
>>
>> This will remove // from file names where they're valid such
>> a "http://blabla/" (using url-handler-mode).
>>
>> The call to completion--merge-suffix is supposed to handle the
>> particular problem you're after, tho, so you might want to try and
>> figure out why it doesn't.
>
> Thanks for the pointer. The problem is the merge point passed by
> completion-pcm--merge-try to completion--merge-suffix and used as the
> starting position for string-match: in the present case, when there is
> only one completion, the merge point is the length of the completion
> string, but since string-match is zero-based, this means it looks for a
> match starting one position after the end of the completion string and
> fails. So the merge point should be one less. However, if there is
> more than one completion, further input is needed, so in this case the
> merge point should not be smaller, otherwise point will not be at the
> end of the string in the minibuffer.
>
> The following patch fixes the problem for me and account for the case of
> multiple completions; does it look ok to you?
As you may have already noticed, there was a typo in the patch that
prevented it from working. But in addition, after fixing the typo so it
correctly eliminates cases of "//", it leaves point on the remaining "/"
instead of just after it, so subsequent attempts to complete don't DTRT.
The following patch fixes this, and also prevents another buggy behavior
of the current implementation (also with -Q) that I encountered while
testing: if you type TAB on e.g. "~/bzr/emacs/tr/lisp/" with point after
"tr", it correctly complete to "~/bzr/emacs/trunk/lisp/", but if you now
type TAB again, the completion is this: "~/bzr/emacs/trunk/lisp//".
This and the bug of my OP are fixed by the patch. Unless you find some
other problem with it, is it ok to commit to emacs-24 in time for the
next pretest?
Steve Berman
=== modified file 'lisp/minibuffer.el'
*** lisp/minibuffer.el 2014-05-04 19:37:56 +0000
--- lisp/minibuffer.el 2014-05-10 21:22:36 +0000
***************
*** 3191,3203 ****
(memq 'star mergedpat)
;; Not `prefix'.
mergedpat))
! ;; New pos from the start.
! (newpos (length (completion-pcm--pattern->string pointpat)))
;; Do it afterwards because it changes `pointpat' by side effect.
(merged (completion-pcm--pattern->string (nreverse mergedpat))))
(setq suffix (completion--merge-suffix merged newpos suffix))
! (cons (concat prefix merged suffix) (+ newpos (length prefix)))))))
(defun completion-pcm-try-completion (string table pred point)
(pcase-let ((`(,pattern ,all ,prefix ,suffix)
--- 3191,3215 ----
(memq 'star mergedpat)
;; Not `prefix'.
mergedpat))
! (completion (and (not (consp (cdr all))) (car all)))
! (pos (length (completion-pcm--pattern->string pointpat)))
! ;; New pos from the start. If it equals the length of the
! ;; completion, make it one less to ensure that string-match
! ;; (which is 0-based) in completion--merge-suffix does not
! ;; start trying to match too late (bug#15419). If there is
! ;; more than one completion, pos is already shorter, so use
! ;; it in order to leave point at the end of the string for
! ;; further minibuffer input.
! (newpos (if (and completion (eq pos (length completion)))
! (1- pos)
! pos))
;; Do it afterwards because it changes `pointpat' by side effect.
(merged (completion-pcm--pattern->string (nreverse mergedpat))))
(setq suffix (completion--merge-suffix merged newpos suffix))
! ;; Use pos instead of newpos here to make sure point is in the
! ;; right place for getting further completions.
! (cons (concat prefix merged suffix) (+ pos (length prefix)))))))
(defun completion-pcm-try-completion (string table pred point)
(pcase-let ((`(,pattern ,all ,prefix ,suffix)
next prev parent reply other threads:[~2014-05-10 21:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-19 15:21 bug#15419: 24.3.50; file name as directory completion problem Stephen Berman
[not found] ` <handler.15419.B.137960413312666.ack@debbugs.gnu.org>
2014-05-07 20:46 ` Stephen Berman
2014-05-08 0:53 ` Stefan Monnier
2014-05-08 14:51 ` Stephen Berman
2014-05-10 21:24 ` Stephen Berman [this message]
[not found] ` <877g5r5tab.fsf@rosalinde.fritz.box>
[not found] ` <jwva9akwh03.fsf-monnier+emacsbugs@gnu.org>
[not found] ` <87a9akxheh.fsf@rosalinde.fritz.box>
2014-05-14 20:40 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a9apgwd2.fsf@rosalinde.fritz.box \
--to=stephen.berman@gmx.net \
--cc=15419@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.