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

Previous Next

Package: emacs;

Reported by: Aaron Cohen <aaron <at> brightbytes.net>

Date: Wed, 28 Jul 2021 19:39:01 UTC

Severity: normal

Tags: fixed

Fixed in version 28.0.50

Done: Juri Linkov <juri <at> linkov.net>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Aaron Cohen <aaron <at> brightbytes.net>
To: Juri Linkov <juri <at> linkov.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 49761 <at> debbugs.gnu.org
Subject: bug#49761: file-cache-minibuffer-complete has become unusable for duplicate file names in MacOSX 27.x emacs
Date: Thu, 29 Jul 2021 14:37:41 -0700
[Message part 1 (text/plain, inline)]
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 <at> 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.
>
[Message part 2 (text/html, inline)]

This bug report was last modified 3 years and 291 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.