all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#41536: uniquify can select non-unique prefix
       [not found] <1806725215.1035270044.1590497113540.JavaMail.root@zimbra39-e7>
@ 2020-05-26 12:56 ` ydirson
  2020-05-27 21:32   ` Noam Postavsky
  0 siblings, 1 reply; 4+ messages in thread
From: ydirson @ 2020-05-26 12:56 UTC (permalink / raw)
  To: 41536

Package: emacs
Version: 26.3

After openning the following two files:

 /tmp/a/b/c
 /tmp/a/x/b/y/c

With style "forward" and all other customization vars as "standard",
the buffer names are respectively:

 b/c
 y/c

With my source-directory layout respecting the "higher-level is most significant"
principle, I would have expected the second buffer to be "x/b/c" instead.

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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#41536: uniquify can select non-unique prefix
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Noam Postavsky @ 2020-05-27 21:32 UTC (permalink / raw)
  To: ydirson; +Cc: 41536

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?





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#41536: uniquify can select non-unique prefix
  2020-05-27 21:32   ` Noam Postavsky
@ 2020-05-27 22:23     ` ydirson
  2020-05-27 22:58       ` ydirson
  0 siblings, 1 reply; 4+ messages in thread
From: ydirson @ 2020-05-27 22:23 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 41536



----- 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





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#41536: uniquify can select non-unique prefix
  2020-05-27 22:23     ` ydirson
@ 2020-05-27 22:58       ` ydirson
  0 siblings, 0 replies; 4+ messages in thread
From: ydirson @ 2020-05-27 22:58 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: 41536


> > 
> > > 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





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-05-27 22:58 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [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

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.