GNU bug report logs - #62776
30.0.50; 'project-find-file' ignoring 'file-name-history'

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Daniel Mendler <mail <at> daniel-mendler.de>, Rudolf Adamkovič <salutis <at> me.com>, 62776 <at> debbugs.gnu.org
Subject: bug#62776: 30.0.50; 'project-find-file' ignoring 'file-name-history'
Date: Wed, 19 Apr 2023 18:49:39 +0300

On 19/04/2023 18:46, Daniel Mendler wrote:
>> IIUC the issue is that is has (added) special handling for file name
>> completion, and predicates that on the name of the history variable. It
>> can/should be combined with an extra check which makes sure that the
>> completion table uses '/' as field separators. Maybe using the
>> `completion-boundaries` thingy. Or just straight calling
>> `completion-boundaries` on the history elements to extract the first
>> segment instead of hardcoding '/'.
> Vertico already handles completion boundaries. This is how the base
> string `vertico--base` is computed. But as already mentioned, this is
> unfortunately not the only issue. The issue is also that
> `project-find-file` removes the base directory. The entries in the
> history hash would need the same treatment.

But they do: the dynamically bound value of file-name-history at the 
moment when completing-read is called contain only the relative file 
names (with base directory removed).

That was the recent change in project.el we are referring to.

Previous Next

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