bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63829: 29.0.90; project-find-file's future history breaks with commo


From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

On 19/08/2023 15:00, sbaugh@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]