From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#15419: 24.3.50; file name as directory completion problem Date: Thu, 08 May 2014 16:51:27 +0200 Message-ID: <87siokias0.fsf@rosalinde.fritz.box> References: <87pps44z2a.fsf@rosalinde.fritz.box> <87r445mi4v.fsf@rosalinde.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1399560808 12901 80.91.229.3 (8 May 2014 14:53:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 May 2014 14:53:28 +0000 (UTC) Cc: 15419@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu May 08 16:53:20 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WiPhI-0007L6-35 for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 May 2014 16:53:20 +0200 Original-Received: from localhost ([::1]:47463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiPhH-0006Gh-Nr for geb-bug-gnu-emacs@m.gmane.org; Thu, 08 May 2014 10:53:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiPh7-00064u-Ks for bug-gnu-emacs@gnu.org; Thu, 08 May 2014 10:53:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WiPh1-0001hZ-Ok for bug-gnu-emacs@gnu.org; Thu, 08 May 2014 10:53:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WiPh1-0001hQ-DY for bug-gnu-emacs@gnu.org; Thu, 08 May 2014 10:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WiPh0-0006NP-Oz for bug-gnu-emacs@gnu.org; Thu, 08 May 2014 10:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 08 May 2014 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15419 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15419-submit@debbugs.gnu.org id=B15419.139956073124430 (code B ref 15419); Thu, 08 May 2014 14:53:02 +0000 Original-Received: (at 15419) by debbugs.gnu.org; 8 May 2014 14:52:11 +0000 Original-Received: from localhost ([127.0.0.1]:56020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WiPgA-0006Ly-H7 for submit@debbugs.gnu.org; Thu, 08 May 2014 10:52:10 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:59034) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WiPg8-0006LL-0x for 15419@debbugs.gnu.org; Thu, 08 May 2014 10:52:09 -0400 Original-Received: from rosalinde.fritz.box ([89.245.100.206]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MO7Ca-1WntrF1TqG-005czX; Thu, 08 May 2014 16:51:57 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 07 May 2014 20:53:36 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.90 (gnu/linux) X-Provags-ID: V03:K0:8DUMHyIUmEVV3xuiI7yBZVJqbUF1j5RE/o/jdTeBKUZ4g4ZMH3U BSDJ2/plp8QNzt7lvYvgrlxW7R5sh0gGLjKUjfg0oTdmRC5yh8ehPDe3uAdqi/mcMy5NaPk xUZagJaIrn6zAfM94dtG71U9ziWlE89PSuhapUhJ88SVdLSBPmf4gZ0mnCgu91flbMy8d/h tPyjbEe5oaOUudtaeqKyQ== X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:88773 Archived-At: On Wed, 07 May 2014 20:53:36 -0400 Stefan Monnier 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))))