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

[Aaron Cohen]

The `-Q` option wasn't working for me, so I stripped everything out of my `init.el` except a few `global-set-key` forms and the initialization of the file cache, presented below.

Both the new cursor behavior and the failure to cycle through duplicate file names still reproduce.

Here's the start of how I load `filecache`: the same procedure is followed for 4 other projects:

```

;; NOTE - WHEN THE FILECACHE GOES BAD, NUKE ALL FILES MATCHING THE PATTERN .#* IN THESE DIRECTORY TREES
(require 'filecache)
;; Add all files under dir to file
(eval-after-load
    "filecache"
  '(progn

     (file-cache-add-directory "~/git/clarity_early_warning")
     (file-cache-add-directory-using-find "~/git/clarity_early_warning/app")
     (file-cache-add-directory-using-find "~/git/clarity_early_warning/bin")
     (file-cache-add-directory-using-find "~/git/clarity_early_warning/config")
     (file-cache-add-directory-using-find "~/git/clarity_early_warning/db")
     (file-cache-add-directory-using-find "~/git/clarity_early_warning/lib")
     (file-cache-add-directory-using-find "~/git/clarity_early_warning/spec")

;; ... etc ...

```

On Thu, Jul 29, 2021 at 12:41 PM Juri Linkov <juri@linkov.net> wrote:

>> > What about the second part of the report, with cursor positioning
>> > after typing an incomplete file name followed by C-TAB: do you see
>> > that problem in your testing?
>>
>> No problem with cursor positioning.
>
> Strange, that's not what I see.  If I type "C-x C-f", type a few
> characters that should match several file names, then press C-TAB, the
> cursor is placed on the first character I typed, making more typing
> cumbersome, because I need first type C-e or somesuch to get to the
> end of what I typed.  Isn't that what you see?

In my testing the cursor is placed at the end of the minibuffer.