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

Previous Next

Full log

Message #71 received at 63829 <at> debbugs.gnu.org (full text, mbox):

From: sbaugh <at> catern.com
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, Juri Linkov <juri <at> linkov.net>,
 63829 <at> debbugs.gnu.org
Subject: Re: bug#63829: 29.0.90; project-find-file's future history breaks
 with common-parent-directory
Date: Sat, 19 Aug 2023 12:00:37 +0000 (UTC)

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> 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.

Sure, if it's something you think is reasonable to enable by default
that's totally fine for me.

A modification that makes some sense to me (although it's hard) is
actually to merge find-file and project-find-file history *more*.  Right
now a path in the history can only be adjusted for the current project
if it was originally added to the history by project-find-file.  It
might be nice if the adjustment worked for paths added by find-file too,
although that is tricky to do efficiently since they don't (yet?) have
the project embedded in them with a text property.

Previous Next

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