On 26/03/2025 13:48, Ship Mints wrote:
> On Tue, Mar 25, 2025 at 11:11 PM Dmitry Gutov <dmitry@gutov.dev
> <mailto:dmitry@gutov.dev>> wrote:
>
> On 25/03/2025 17:42, Ship Mints wrote:
> > I just got bitten by project-buffers not reporting all the buffers
> > "strictly" related to the project because project.el thinks there
> are
> > two different projects. I can't imagine that me and the
> colleagues of
> > mine that use convenience symlinks are the only ones to see these
> kinds
> > of inconsistencies. Just thought I'd leave a concrete example in
> this
> > thread.
>
> Thanks for the example.
>
> > I've turned my advice back on to force truename canonicalization
> for the
> > time being.
>
> Does that change really help?
>
>
> It does for unifying project-name and project-root.
Do they have corresponding scenarios that cause confusion?
> In my testing, what it results in, is showing only the buffers
> belonging
> to the "canonical" project, both when project-switch-buffer is called
> when in it, or when inside a "symlinked" version. Buffers visited from
> the "symlinked" project are not suggested in completion anymore.
>
> When reproducing, try using find-file (C-x C-f) to open the buffers.
>
>
> Yes, indeed, project-buffers also needs some help.
We could add a user option for project-buffers specifically, as one
approach.
I assume this would be the same option that canonicalizes project-roots so it's all synchronized.
> Thanks for the continuing discussion.
>
> WRT projectile, having only eyeballed the code (I haven't used it), it
> seems truename use is not optional. It looks like projectile-project-
> buffer-p is defined in terms of truename https://github.com/bbatsov/
> projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
> projectile.el#L1775 <https://github.com/bbatsov/projectile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
> projectile.el#L1775>, project-root caches the truename (but I see a bug
> in the code which doesn't normalize dir on the way in so users likely
> get odd results) https://github.com/bbatsov/projectile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385
> <https://github.com/bbatsov/projectile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>, the
> file cache is in terms of truename https://github.com/bbatsov/
> projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/
> projectile.el#L1262 <https://github.com/bbatsov/projectile/
> blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1262>. </>
I wonder how it affects Projectile's performance over Tramp.
No idea. But I can say that I have wrapped a bunch of project.el functions to avoid remote file operations based on a personal user option (some of my users are heavy Trampers, some hosts are slow). But the way I've done it is a blanket inhibition, not project-specific or some other appropriate criteria which would be nicer. Perhaps a .project.eld file with variables akin to dir-locals that project could consult. I haven't had the time to think that through.
I've also implemented personal 'consult' project and related buffer-matching functions to handle project root canonicalization. Those functions are not in terms of project-buffers and perhaps should be as they miss out on back-end specializations. I've started a discussion in the consult repo to offer to contribute PRs over there.