From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Cohen Newsgroups: gmane.emacs.bugs Subject: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs Date: Mon, 2 Aug 2021 13:12:07 -0700 Message-ID: References: <87o8alvwby.fsf@mail.linkov.net> <83bl6lrnrh.fsf@gnu.org> <878s1pvunb.fsf@mail.linkov.net> <838s1osyv1.fsf@gnu.org> <87y29ovrgj.fsf@mail.linkov.net> <87v94su45t.fsf@mail.linkov.net> <8335rws641.fsf@gnu.org> <87lf5nisyo.fsf@mail.linkov.net> <87k0l5j1u1.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000022f22305c8993165" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31683"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49761@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 02 22:13:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mAeJC-000856-1E for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Aug 2021 22:13:10 +0200 Original-Received: from localhost ([::1]:57584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mAeJA-00026G-G2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Aug 2021 16:13:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46226) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mAeJ5-000268-2J for bug-gnu-emacs@gnu.org; Mon, 02 Aug 2021 16:13:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56035) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mAeJ4-00075t-RU for bug-gnu-emacs@gnu.org; Mon, 02 Aug 2021 16:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mAeJ4-00032V-3Z for bug-gnu-emacs@gnu.org; Mon, 02 Aug 2021 16:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Cohen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Aug 2021 20:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49761 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 49761-submit@debbugs.gnu.org id=B49761.162793517111666 (code B ref 49761); Mon, 02 Aug 2021 20:13:02 +0000 Original-Received: (at 49761) by debbugs.gnu.org; 2 Aug 2021 20:12:51 +0000 Original-Received: from localhost ([127.0.0.1]:39348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mAeIs-000325-MK for submit@debbugs.gnu.org; Mon, 02 Aug 2021 16:12:51 -0400 Original-Received: from mail-oi1-f182.google.com ([209.85.167.182]:35488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mAeIq-00031t-UT for 49761@debbugs.gnu.org; Mon, 02 Aug 2021 16:12:49 -0400 Original-Received: by mail-oi1-f182.google.com with SMTP id n16so18960170oij.2 for <49761@debbugs.gnu.org>; Mon, 02 Aug 2021 13:12:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightbytes.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QwHAVOeDGv0pL+ffC8vvz1K95BuM83YJTiG+fIabHko=; b=AlERTNXmyo3KPBXWgIPZU6egbP8Gzw3imD0O3wKB9e0Y4uF40Yl/t6nE/CdZ0db1EP 5cOJ09oDFksTPhy1UCIW0G2dOcrjW6cZwdKenEj1y4GsbAKV8IHvbhg5d50rLc4mkMPO uc4MefU0GxFEAltG0unHyUEOkfsV5ltsm6qss= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QwHAVOeDGv0pL+ffC8vvz1K95BuM83YJTiG+fIabHko=; b=Y3B7wm2UwGxSTPk66HV/joH9JbhDNbHATfj4S/dNicjrI0v5dRxEZLHDj/bjLA7aIb uTQEJJBn4r9UPPqwjRLaaCpw5+hWZzR7j90n5A2A4CLCrQB6+l5N+ICkrVj9iV/w905K N4xC5WA+YUrYYeCmq3MDrm66sDAYV3IQ9m06R8ok/ghsNX8u89lZALeOJZQaCRja40lx 2S3Yu5m//De2U1KZTabgDVPbTt8syj6bUDX5Ot0YgPpVPx++BLDhjFFlt7qM5NOcYjv+ Or+HqvlcENCAKY5cckcwYZriov1AH/+Ok+eNcZ0q9WwOHRruw6gcXDfKYNPlZ+7bFHgy Uk0A== X-Gm-Message-State: AOAM532bo3WPHZk5ojhQJmufDzlQYUg+Zz0A/167g/pkS1sSxOmaE7YY 0WlkXLirD/vI+ivRc/HK2ZxSh5Wxg/mBvkjueWzBsg== X-Google-Smtp-Source: ABdhPJwlwHJM8JNiWjoTZAEiCSwxaQu7amDLAcpepik+tv9xyKHyaftf6iLXxEWFzX+/aZiKE3b3jPrRctoRQOteMok= X-Received: by 2002:aca:2b07:: with SMTP id i7mr334879oik.97.1627935163472; Mon, 02 Aug 2021 13:12:43 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211081 Archived-At: --00000000000022f22305c8993165 Content-Type: text/plain; charset="UTF-8" Oh, and I've confirmed that the workaround of `C-u C-Tab` works great for cycling through files when `C-Tab` would otherwise get stuck. So, I'm good until the next official release. On Mon, Aug 2, 2021 at 1:02 PM Aaron Cohen wrote: > Very much appreciated!! > > And thank you for investigating and isolating the issue: I had > misidentified the actual problem and didn't provide a duplication recipe, > making your job much harder. > > I promise to do better next time, and provide a test case. :-) > > Thanks again!! > > On Sun, Aug 1, 2021 at 1:41 AM Juri Linkov wrote: > >> tags 49761 fixed >> close 49761 28.0.50 >> thanks >> >> > Well, it's now the default behavior. It wasn't previously. :-) >> >> And new is not always better ;-) >> >> So now the new behavior (that became old now) was fixed >> in the master branch for Emacs 28, and all test cases >> that you presented work completely as expected. >> Thanks for helping to understand where the problem was. >> >> BTW, after the fix, the following additional information >> is not necessary, but I discovered that in old versions >> you can use the prefix argument to force C-TAB cycling. >> >> An excerpt from etc/NEWS.20: >> >> ** file-cache-minibuffer-complete now accepts a prefix argument. >> With a prefix argument, it does not try to do completion of >> the file name within its directory; it only checks for other >> directories that contain the same file name. >> Thus, given the file name Makefile, and assuming that a file >> Makefile.in exists in the same directory, ordinary >> file-cache-minibuffer-complete will try to complete Makefile to >> Makefile.in and will therefore never look for other directories that >> have Makefile. A prefix argument tells it not to look for longer >> names such as Makefile.in, so that instead it will look for other >> directories--just as if the name were already complete in its present >> directory. >> >> and a comment from bindings.el: >> >> ;; The prefix argument works around a bug in the minibuffer completion. >> ;; The completion function doesn't distinguish between the states: >> ;; >> ;; "Multiple completions of name" (eg, Makefile, Makefile.in) >> ;; "Name available in multiple directories" (/tmp/Makefile, >> ~me/Makefile) >> ;; >> ;; The default is to do the former; a prefix arg forces the latter. >> > --00000000000022f22305c8993165 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh, and I've confirmed that the workarou= nd of `C-u C-Tab` works great for cycling through files when `C-Tab` would = otherwise get stuck.=C2=A0 So, I'm good until the next official release= .

On Mon, Aug 2, 2021 at 1:02 PM Aaron Cohen <aaron@brightbytes.net> wrote:
Very much appreciated!!<= /div>

And than= k you for investigating and isolating the issue: I had misidentified the ac= tual problem and didn't provide a duplication recipe, making your job m= uch harder.

I promise to do better next time, and provide a test case. =C2=A0:-)

Thanks a= gain!!

On Sun, Aug 1, 2021 at 1:41 AM Juri Linkov <juri@linkov.net> wrote:
tags 49761 fixed
close 49761 28.0.50
thanks

> Well, it's now the default behavior.=C2=A0 It wasn't previousl= y.=C2=A0 :-)

And new is not always better ;-)

So now the new behavior (that became old now) was fixed
in the master branch for Emacs 28, and all test cases
that you presented work completely as expected.
Thanks for helping to understand where the problem was.

BTW, after the fix, the following additional information
is not necessary, but I discovered that in old versions
you can use the prefix argument to force C-TAB cycling.

An excerpt from etc/NEWS.20:

=C2=A0 ** file-cache-minibuffer-complete now accepts a prefix argument.
=C2=A0 With a prefix argument, it does not try to do completion of
=C2=A0 the file name within its directory; it only checks for other
=C2=A0 directories that contain the same file name.
=C2=A0 Thus, given the file name Makefile, and assuming that a file
=C2=A0 Makefile.in exists in the same directory, ordinary
=C2=A0 file-cache-minibuffer-complete will try to complete Makefile to
=C2=A0 Makefile.in and will therefore never look for other directories that=
=C2=A0 have Makefile.=C2=A0 A prefix argument tells it not to look for long= er
=C2=A0 names such as Makefile.in, so that instead it will look for other =C2=A0 directories--just as if the name were already complete in its presen= t
=C2=A0 directory.

and a comment from bindings.el:

=C2=A0 ;; The prefix argument works around a bug in the minibuffer completi= on.
=C2=A0 ;; The completion function doesn't distinguish between the state= s:
=C2=A0 ;;
=C2=A0 ;;=C2=A0 =C2=A0"Multiple completions of name" (eg, Makefil= e, Makefile.in)
=C2=A0 ;;=C2=A0 =C2=A0"Name available in multiple directories" (/= tmp/Makefile, ~me/Makefile)
=C2=A0 ;;
=C2=A0 ;; The default is to do the former; a prefix arg forces the latter.<= br>
--00000000000022f22305c8993165--