bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs

[Aaron Cohen <aaron@brightbytes.net>]

[-- Attachment #1: Type: text/plain, Size: 2223 bytes --]

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 <eliz@gnu.org> wrote:

> > From: Juri Linkov <juri@linkov.net>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  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.
>

[-- Attachment #2: Type: text/html, Size: 4283 bytes --]