[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#41536: uniquify can select non-unique prefix
From: |
ydirson |
Subject: |
bug#41536: uniquify can select non-unique prefix |
Date: |
Thu, 28 May 2020 00:23:12 +0200 (CEST) |
----- Mail original -----
> De: "Noam Postavsky" <npostavs@gmail.com>
> À: ydirson@free.fr
> Cc: 41536@debbugs.gnu.org
> Envoyé: Mercredi 27 Mai 2020 23:32:04
> Objet: Re: bug#41536: uniquify can select non-unique prefix
>
> ydirson@free.fr writes:
>
> > In my case the "y" level is even a python package for modules
> > containing abstract
> > classes, call it "lib" -- you'll understand that "lib/foo.py" is
> > not really
> > helpful, when other packages could have a module of the same name
> > in a "lib/"
> > subpackage.
>
> I agree this can be annoying in many cases, but how do you expect
> Emacs
> to know which directory names should be considered? Have a backlist
> of
> "too generic" words like "lib", "utils", "config", etc?
No, I'd rather using a couple of rules, but I do agree finding a one-fits-all
heuristic is likely hard to get. Let me think aloud a bit, in the hope it will
stir ideas from others as well.
(by the way, I did not look at the code yet, getting the gist of the current
heuristic
will be obviously useful)
My initial thought when seeing a/x/b/y/c vs. a/b/c resolved as y/c vs b/c was
something like "never select a dirname for one buffer if it exists for all".
Obviously that formulation is not sufficient, as it would not handle the a/b/c
vs.
b/a/c case, but maybe but as a work approximation we can leave the latter case
for later rule refining if needed..
That rule would result, for my a/x/b/y/c vs. a/b/c case, in "(x/)?(y/)?c" vs.
just "c".
That could be an option, although arguably the "c" part does appear in both
paths and
we don't want strip it.
When only 2 files are at hand, maybe a heuristic like "strip all common leading
dirs and take the next" would fit: that would let a/x/b/y/c vs. a/b/c to resolve
as x/c vs. b/c. The idea is that an outer directory is likely to carry more
semantic
weight.
With more than 2 files if ambiguities arise, it is likely acceptable in many
cases
to keep this first dir and recurse. Say we add a/x/t/c to the lot, that would
give
x/b/c, x/t/c, and b/c.
Does that make any sense to anyone beside me ?
Best regards,
--
Yann