From: ydirson@free.fr
To: Noam Postavsky <npostavs@gmail.com>
Cc: 41536@debbugs.gnu.org
Subject: bug#41536: uniquify can select non-unique prefix
Date: Thu, 28 May 2020 00:58:58 +0200 (CEST) [thread overview]
Message-ID: <908011962.1041896177.1590620338618.JavaMail.root@zimbra39-e7> (raw)
In-Reply-To: <521374123.1041844255.1590618192543.JavaMail.root@zimbra39-e7>
> >
> > > 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.
For the record, another case where the current heuristic is wrong for me:
projname/b/c/d vs. projname/a/b/c/d. It is currently resolved as "projname/d"
vs. "a/d", presumably by removing all common _suffix_ until a diff is found,
whereas with a heuristic of removing all common _prefix_ it would have
settled with "b/d" vs. "a/d", which would have made much more sense.
Hope this can clarify further :)
--
Yann
prev parent reply other threads:[~2020-05-27 22:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1806725215.1035270044.1590497113540.JavaMail.root@zimbra39-e7>
2020-05-26 12:56 ` bug#41536: uniquify can select non-unique prefix ydirson
2020-05-27 21:32 ` Noam Postavsky
2020-05-27 22:23 ` ydirson
2020-05-27 22:58 ` ydirson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=908011962.1041896177.1590620338618.JavaMail.root@zimbra39-e7 \
--to=ydirson@free.fr \
--cc=41536@debbugs.gnu.org \
--cc=npostavs@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).