unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dmitry@gutov.dev>
To: sbaugh@catern.com
Cc: Spencer Baugh <sbaugh@janestreet.com>,
	Juri Linkov <juri@linkov.net>,
	63829@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	[thread overview]
Message-ID: <24706934-8acd-2047-7db9-11b7d34ddd0e@gutov.dev> (raw)
In-Reply-To: <871qfzi6mz.fsf@catern.com>

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	other threads:[~2023-08-21  1:51 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-01 22:32 bug#63829: 29.0.90; project-find-file's future history breaks with common-parent-directory Spencer Baugh
2023-06-02  6:47 ` Eli Zaretskii
2023-06-03 12:19   ` Dmitry Gutov
2023-06-03 12:48     ` Eli Zaretskii
2023-06-03 13:48       ` Dmitry Gutov
2023-06-03  2:30 ` Dmitry Gutov
2023-06-03 11:00   ` Spencer Baugh
2023-06-04 16:36     ` Juri Linkov
2023-06-06  1:40       ` Dmitry Gutov
2023-06-06 15:55         ` Spencer Baugh
2023-08-10 12:02           ` sbaugh
2023-08-12  1:23           ` Dmitry Gutov
2023-08-14 20:12             ` Spencer Baugh
2023-08-14 22:47               ` sbaugh
2023-08-16  1:49                 ` Dmitry Gutov
2023-08-16  2:57                   ` sbaugh
2023-08-17  2:14                     ` Dmitry Gutov
2023-08-17 19:41                       ` Spencer Baugh
2023-08-17 20:12                         ` Spencer Baugh
2023-08-18 20:57                           ` Spencer Baugh
2023-08-19  2:14                             ` Dmitry Gutov
2023-08-20 17:23                             ` Juri Linkov
2023-08-20 17:16                           ` Juri Linkov
2023-08-21  1:15                             ` Dmitry Gutov
2023-08-23  2:13                           ` Dmitry Gutov
2023-08-19  2:08                         ` Dmitry Gutov
2023-08-19 12:00                           ` sbaugh
2023-08-21  1:51                             ` Dmitry Gutov [this message]
2023-08-20 17:20                         ` Juri Linkov
2023-08-21  1:43                           ` Dmitry Gutov
2023-08-21  7:06                             ` Juri Linkov
2023-08-23  0:37                               ` Dmitry Gutov
2023-08-23  2:26                         ` Dmitry Gutov
2023-08-23 17:52                           ` Juri Linkov
2023-08-23 18:25                             ` Dmitry Gutov
2023-08-20 17:13                       ` Juri Linkov
2023-08-21  1:17                         ` Dmitry Gutov
2023-08-21  6:58                           ` Juri Linkov
2023-08-23  0:27                             ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24706934-8acd-2047-7db9-11b7d34ddd0e@gutov.dev \
    --to=dmitry@gutov.dev \
    --cc=63829@debbugs.gnu.org \
    --cc=juri@linkov.net \
    --cc=sbaugh@catern.com \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).