On Tue, Mar 25, 2025 at 9:01 AM Ship Mints wrote: > On Tue, Mar 25, 2025 at 8:54 AM Daniel Colascione > wrote: > >> >> >> On March 25, 2025 6:54:34 AM EDT, Ship Mints wrote: >> >On Mon, Mar 24, 2025 at 10:16 PM Dmitry Gutov wrote: >> > >> >> On 24/03/2025 17:15, Ship Mints wrote: >> >> > I'm curious to hear more about why people would object to >> (project-root >> >> > project-obj) being canonicalized. I don't think many people ever >> >> > manually enter project dirs. The persisted known projects, I'd >> think, >> >> > would also benefit from no duplicates. >> >> >> >> I wonder if you yourself would prefer for all buffer-file-name values, >> >> and default-directory values, to be canonicalized as well. >> >> >> >> The same reasoning would seem to apply to them too anyway. >> >> >> > >> >Ochen funny. I'll submit a separate patch for that one day (sarcasm >> doesn't >> >work in email, sorry). >> > >> >In the meantime, I maintain my view that project.el needs to report >> uniform >> >project names and roots for identical projects approached from different >> >places, even if optional. >> > >> >I just took a look at projectile.el, which I'd never looked at before >> >because I prefer using/improving core features. It has a longer user >> >history to see what they've experienced (and it looks like some of >> >project.el's approach is copied almost verbatim e.g., the implementation >> of >> >project-name). projectile seems to both have users that want symlink >> >chasing and those that don't (looks like ClearCase users--but out of >> >necessity not desire?). As those concerns seem to be project dependent, >> we >> >could an option that is a list of paths or matchers to include/exclude >> from >> >chasing, and also a project root semaphore file or project config as I >> >suggested in another message in this thread. >> > >> >I'd enable chasing as my default, opt out in a specific project should I >> >ever have one that needs it rather than the other way around, and enjoy >> >project-name and project-root uniformity. >> > >> >-Stephane >> >> Eli is right. You want either global path normalization or you don't. >> Doing it peacemeal at the project level might satisfy some small immediate >> need, but it won't solve the whole problem and will inevitably cause >> downstream problems due to the incoherence. >> >> Also, it's just not universally true that I want to regard the "real" >> version of something as its realpath. People use symlinks differently. In a >> world in which we had ubiquitous unprivileged bind mounts *and* symlinks, >> the realpath as identity concept might be more powerful, but we don't. >> > > Again...I'm not saying universally, I'm saying optionally, and preferably > flexibly optional. > 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. I've turned my advice back on to force truename canonicalization for the time being.