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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: sbaugh <at> catern.com
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, Juri Linkov <juri <at> linkov.net>, 63829 <at> debbugs.gnu.org
Subject: bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory
Date: Mon, 21 Aug 2023 04:51:33 +0300

On 19/08/2023 15:00, sbaugh <at> catern.com wrote:

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

I'm being a tad skittish about it because once we add the var, it will 
likely have to stay around for a long time. And a long name is both 
unwieldy and less prone to extensibility.

One of the ways to make it shorter, is to thing around different 
non-intersecting behaviors that could be enabled by it. If e.g. it could 
have values "default" (don't do anything) and "relativize" (and ... 
"relativize existing"? as Juri brought up), then the var could be called

  project-file-history-behavior

with values t, 'relativize and 'relativize-existing. Or something like 
that. We could still drop the option for now and enable the new behavior 
by default, unless somebody objects.

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

I don't know, it seems like we'd do extra work up front, going through 
file-name-history, while most people won't take advantage of it. If we 
could do that lazily (with a generator function of some sort), that 
would of course be preferable. As it is, though, one could just run a 
small script once, and convert all the entries to use later.

What's the scenario when this doesn't work? People using 'find-file' to 
quickly jump to a file in the same dir and then wanting to use it in 
history during project-find-file in another project?

Previous Next

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