[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49761: file-cache-minibuffer-complete has become unusable for duplic

From: Aaron Cohen
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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]