sbaugh@catern.com writes:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>> On 11/07/2023 02:45, Spencer Baugh wrote:
>>> Dmitry Gutov <dmitry@gutov.dev> writes:
>>>> On 27/06/2023 23:01, Spencer Baugh wrote:
>>>>> OK, how about this?
>>>>
>>>> Maybe we should go in the other direction? And call
>>>> abbreviate-file-name on them?
>>>>
>>>> Because otherwise in project-prompt-project-dir we'll always show the
>>>> expanded directory names, taking up extra space and usually repeating
>>>> the full name of the user's home directory for no good reason.
>>> That seems reasonable if we let-bind directory-abbrev-alist to nil
>>> around it; otherwise we'll be dependent on the user's configuration and
>>> we might add a directory in one way, and then they add a new value to
>>> directory-abbrev-alist and we add it again a second way.
>>
>> That's also fair.
>>
>>> Although maybe that's fine?  And probably users of
>>> directory-abbrev-alist would like to have those abbreviations show up in
>>> project-prompt-project-dir.
>>
>> They probably would. But indeed if the list was saved with one
>> configuration, and read with another, it could lead to a mistake.
>>
>>> Also we could always call abbreviate-file-name at
>>> project-prompt-project-dir time.
>>
>> Meaning it will be called N times (for the number of projects) every
>> time the list is displayed, instead of just once, when the project is
>> saved/visited. But maybe it's fine too? How slow could that be?
>
> I was sad about this but I think I've got the solution now: We just
> maintain project--list in abbreviated form and project-list-file in
> expanded form.
>
> I think that solves all the problems: the persistent file is independent
> of user configuration, so if the user changes their abbreviations
> they'll get new ones the next time the file is read (presumably the next
> time they run Emacs).  But project--list is abbreviated, so
> project-prompt-project-dir gets abbreviated dirs.
>
> It does mean that if they change their directory-abbrev-alist while
> Emacs is running they could get duplicate entries, but that already
> could happen before this patch, and it's not a big problem IMO.
>
> See patch below.

Oops, this patch needed a few tweaks.  Especially, skipping the
expansion and abbreviation for remote files, to avoid making unnecesary
remote connections.