On Wed, Mar 26, 2025 at 9:00 AM Dmitry Gutov wrote: > On 26/03/2025 13:48, Ship Mints wrote: > > On Tue, Mar 25, 2025 at 11:11 PM Dmitry Gutov > > 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 > 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 > > > blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/projectile.el#L1385>, the > > file cache is in terms of truename https://github.com/bbatsov/ > > projectile/blob/55db082cdf7b849335ccf24b7ba5aa2607d6fe93/ > > projectile.el#L1262 > 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.