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: Daniel Mendler <mail <at> daniel-mendler.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>, 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 19:07:15 +0200

On 4/19/23 17:49, Dmitry Gutov wrote:
> 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.

Ok okay, thanks! I didn't understand that. This makes a lot of sense
since then the history only contains valid values. Then you are right
that it is actually quite easy to repair the completion boundary issue
in `vertico--history-hash`.

Daniel

Previous Next

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