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: Thu, 29 Jul 2021 23:41:12 -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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008ae33405c8518310" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39041"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49761@debbugs.gnu.org, Juri Linkov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 30 16:23:17 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 1m9TPx-0009t5-4X for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Jul 2021 16:23:17 +0200 Original-Received: from localhost ([::1]:49222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m9TPu-00085E-Re for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Jul 2021 10:23:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41768) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m9TPi-000851-Vu for bug-gnu-emacs@gnu.org; Fri, 30 Jul 2021 10:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49121) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m9TPi-0006Cs-OI for bug-gnu-emacs@gnu.org; Fri, 30 Jul 2021 10:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m9TPi-0005hF-Ks for bug-gnu-emacs@gnu.org; Fri, 30 Jul 2021 10:23: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: Fri, 30 Jul 2021 14:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49761 X-GNU-PR-Package: emacs Original-Received: via spool by 49761-submit@debbugs.gnu.org id=B49761.162765493721798 (code B ref 49761); Fri, 30 Jul 2021 14:23:02 +0000 Original-Received: (at 49761) by debbugs.gnu.org; 30 Jul 2021 14:22:17 +0000 Original-Received: from localhost ([127.0.0.1]:60660 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9TOy-0005fV-Kc for submit@debbugs.gnu.org; Fri, 30 Jul 2021 10:22:17 -0400 Original-Received: from mail-oi1-f181.google.com ([209.85.167.181]:41689) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m9MDS-00086X-6P for 49761@debbugs.gnu.org; Fri, 30 Jul 2021 02:41:55 -0400 Original-Received: by mail-oi1-f181.google.com with SMTP id 21so11838569oin.8 for <49761@debbugs.gnu.org>; Thu, 29 Jul 2021 23:41:54 -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=puIynhILMeBIPLIjtWstV5/FFsjcb7bhsPzxfdX2GCM=; b=DQNzj9e1WJH/6J152TE8kPsCR70TkRTElReXoOCprIkWb6gSNbQJG5uUQJon7/45SB 7d476a6gvAwEY6iTEK0SWvImGBWiqVaJyDXl2ejbU/Lf3Ztuh8tD+bw/W26nwaKT6UVH 1tO3RgkLF4IkxRc2ttVgisXAibXVhqqvFEHng= 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=puIynhILMeBIPLIjtWstV5/FFsjcb7bhsPzxfdX2GCM=; b=qAibBbkxDDqDetix/iOUc+b+iEbj4TN8SNiAv36uoIMwsU8Z7Zr+f7g9y0rYzOEVJS WO9jrQN3FPB0nlbIVbOdyNb2jsQRHXySSMmq/OC1X6EF0FwA+jpq6w2TpwU49tijJc1w gyzJDBUt0LjDvA6KPa25ORgQZO5E+TTebox1VgwqR/k88ziCb1LJyBHqkuEPG9NwckcQ zWiyAGUy80/Puk3/jgCHZR2lzi3tVtpZBaSyn4SS+T5gWZ1/bk3fwLqquKzYHGUQ1JPw FS2KGRn6JZsaqfUOroydXrqpzyIZeY+7poQHkKNWDdjrE1nAvaCEoh0n+fYrlGbl6LDT UttA== X-Gm-Message-State: AOAM530v+Nd18RP9VDixq86pfCkVoqdEB8L1nuxlsbvfyvUC+Xepg74M oXkbAH4n/KUY7PoZhbURPhxtvMEoqVT25Lrt+dkguA== X-Google-Smtp-Source: ABdhPJyBVThVuaLavAGserswRs8jt+bjO8ZsHAMh/JU0mVBqFEDhYmIzsAwPkMx4Erf7xHAkCZ0JVDF5S5w0dwMoNKQ= X-Received: by 2002:a05:6808:144a:: with SMTP id x10mr852810oiv.68.1627627308371; Thu, 29 Jul 2021 23:41:48 -0700 (PDT) In-Reply-To: <8335rws641.fsf@gnu.org> X-Mailman-Approved-At: Fri, 30 Jul 2021 10:22:15 -0400 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:210913 Archived-At: --0000000000008ae33405c8518310 Content-Type: text/plain; charset="UTF-8" Comments: 2. The cycling is broken if you have one file without an extension with a given name and another file with the same name and an extension. For example, all 5 of my projects are currently Ruby on Rails repos. Every RoR project has a `Gemfile` and a `Gemfile.lock`. When I try to find a particular Gemfile, C-Tab gets stuck on the first one. This has always been the case with C-Tab, so it doesn't bother me, though if there is a workaround I'd love to know it. 3. Yes, I see the message "[File Cache: complete but not unique]" whenever it gets stuck. This has always been the case for 2, above, and in Emacs 27.x (and presumably 28.x) it is the case when a duplicated file has a duplicate and also another file with a similar ending. In my case, there are 9 files named `dashboard.rb` across several projects, and even more files across several projects that follow the pattern `*_dashboard.rb`. 4. The cursor-jumping-to-the-beginning-of-the-filename behavior is new in Emacs 27.x. It doesn't happen in case 2, above ... though that's because the overlap termination location in that case is at the end of the completed file name (the dot in `Gemfile.lock`). Whereas in the new behavior, the overlap termination location is at the beginning (e.g. in my project, the underscore in `db_dashboard.rb` or `homepage_dashboard.rb`). In any case, the larger issue is that a prefix overlap is now causing C-Tab to get stuck. The point goes where it should to assist the User in resolving the overlap. It's not where the point goes but rather that Emacs gets stuck on the common suffix that is the new issue. On Thu, Jul 29, 2021 at 10:50 PM Eli Zaretskii wrote: > > From: Juri Linkov > > Cc: Eli Zaretskii , 49761@debbugs.gnu.org > > Date: Fri, 30 Jul 2021 01:49:18 +0300 > > > > 4. 'make C-TAB' then the completions buffer is displayed and the cursor > > jumps to the beginning because there are completions that don't begin > > with the same prefix "make" such as flymake.el, pmake.el, > ob-makefile.el. > > Is this reasonable behavior? It seems to try second-guessing what the > user will do next, but that guess is not necessarily correct. > --0000000000008ae33405c8518310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments:

2. The cycling is broken if you have one file without an extension= with a given name and another file with the same name and an extension.=C2= =A0 For example, all 5 of my projects are currently Ruby on Rails repos.=C2= =A0 Every RoR project has a `Gemfile` and a `Gemfile.lock`.=C2=A0 When I tr= y to find a particular Gemfile, C-Tab gets stuck on the first one.=C2=A0 Th= is has always been the case with C-Tab, so it doesn't bother me, though= if there is a workaround I'd love to know it.

<= /div>
3. Yes, I see the message "[File Cache: complete but not unique]= " whenever it gets stuck.=C2=A0 This has always been the case for 2, a= bove, and in Emacs 27.x (and presumably 28.x) it is the case when a duplica= ted file has a duplicate and also another file with a similar ending.=C2=A0= In my case, there are 9 files named `dashboard.rb` across several projects= , and even more files across several projects that follow the pattern `*_da= shboard.rb`.

4. The cursor-jumpi= ng-to-the-beginning-of-the-filename behavior is new in Emacs 27.x.=C2=A0 It= doesn't happen in case 2, above ... though=C2=A0that's because the= overlap termination location in that case is at the end of the completed f= ile name (the dot in `Gemfile.lock`). Whereas in the new behavior, the over= lap termination location is at the beginning (e.g. in my project, the under= score in `db_dashboard.rb` or `homepage_dashboard.rb`). =C2=A0

In any case, the larger issue is that a pref= ix overlap=C2=A0is now causing C-Tab to get stuck.=C2=A0 The point goes whe= re it should to assist the User in resolving the overlap.=C2=A0 It's no= t where the point goes but rather that Emacs gets stuck on the common suffi= x that is the new issue.





=


On Thu, Jul 29, 2021 at 10:50 PM Eli Zaretskii <= eliz@gnu.org> wrote:
> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,=C2=A0 49761@debbugs.gnu.org
> Date: Fri, 30 Jul 2021 01:49:18 +0300
>
> 4. 'make C-TAB' then the completions buffer is displayed and t= he cursor
>=C2=A0 =C2=A0 jumps to the beginning because there are completions that= don't begin
>=C2=A0 =C2=A0 with the same prefix "make" such as flymake.el,= pmake.el, ob-makefile.el.

Is this reasonable behavior?=C2=A0 It seems to try second-guessing what the=
user will do next, but that guess is not necessarily correct.
--0000000000008ae33405c8518310--