GNU bug report logs - #63829
29.0.90; project-find-file's future history breaks with common-parent-directory

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Thu, 1 Jun 2023 22:33:02 UTC

Severity: normal

Found in version 29.0.90

Full log


View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: sbaugh <at> catern.com, 63829 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory
Date: Sat, 19 Aug 2023 05:08:38 +0300
On 17/08/2023 22:41, Spencer Baugh wrote:
> Dmitry Gutov <dmitry <at> gutov.dev> writes:
>> -         (file (funcall project-read-file-name-function
>> -                        "Find file" all-files nil 'file-name-history
>> -                        suggested-filename)))
>> +         (file
>> +          (let ((file-name-history (mapcar
>> +                                    (lambda (f)
>> +                                      (or (project--expand-file-name
>> f project) f))
>> +                                    file-name-history)))
>> +            (funcall project-read-file-name-function
>> +                     "Find file" all-files nil 'file-name-history
>> +                     suggested-filename))))
>> +    (when history-add-new-input
>> +      ;; Have to re-add it here because of the let-binding above.
>> +      (add-to-history 'file-name-history
>> +                      (propertize file 'project (project-root project))))
>>       (if (string= file "")
>>           (user-error "You didn't specify the file")
>>         (find-file file))))
> 
> This seems good, sure.  But doesn't this make the history entries appear
> twice?

It doesn't, since whatever modification to file-name-history is done 
inside project-read-file-name-function is erased when the surrounding 
'let' form (pre-altering its value) returns.

> Maybe we should just pull the history-adding functionality out of
> project-read-file-name-function entirely.  I've tried doing that below.

Just for project-find-dir, right? That makes sense.

> Also, I realized just now that this should probably affect
> project-find-dir as well, as should my previous patch adding
> project-relative future history.  (I actually coincidentally just now
> got a user request for "switch between projects and stay in the same
> dir")

^^

> So here's a revised version of this history change which also affects
> project-find-dir.  In a subsequent mail I'll send a patch for the
> "future history" behavior of project-find-dir too.  (yet to be written)

That ones looks good too (I'll go over the cosmetics a little later).

Regarding project-file-name-history-relativize, I wanted to ask about a 
shorter name, but... it seems like there aren't many to be had.

Also originally I wanted to just enable the feature and then see what 
actual modifications people will want. Perhaps some will ask for 
find-file and project-find-file histories to be totally separate 
instead? Or maybe not.




This bug report was last modified 1 year and 297 days ago.

Previous Next


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