unofficial mirror of bug-gnu-emacs@gnu.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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).