all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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: Thu, 08 May 2014 16:51:27 +0200	[thread overview]
Message-ID: <87siokias0.fsf@rosalinde.fritz.box> (raw)
In-Reply-To: <jwvha51f62c.fsf-monnier+emacsbugs@gnu.org> (Stefan Monnier's message of "Wed, 07 May 2014 20:53:36 -0400")

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?

Steve Berman

=== modified file 'lisp/minibuffer.el'
*** lisp/minibuffer.el	2014-05-04 19:37:56 +0000
--- lisp/minibuffer.el	2014-05-08 14:41:56 +0000
***************
*** 3191,3198 ****
                           (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))))
  
--- 3191,3208 ----
                           (memq 'star  mergedpat)
                           ;; Not `prefix'.
                           mergedpat))
! 	   (completion (and (not (consp (cdr all))) 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))))
  






  reply	other threads:[~2014-05-08 14:51 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 [this message]
2014-05-10 21:24         ` Stephen Berman
     [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=87siokias0.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.