GNU logs - #41536, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#41536: uniquify can select non-unique prefix
Resent-From: ydirson@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 May 2020 12:57:02 +0000
Resent-Message-ID: <handler.41536.B.159049781429678 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 41536 <at> debbugs.gnu.org
Date: Tue, 26 May 2020 14:56:50 +0200 (CEST)
From: ydirson@HIDDEN
Message-ID: <1422112800.1035313346.1590497810370.JavaMail.root@zimbra39-e7>
In-Reply-To: <1806725215.1035270044.1590497113540.JavaMail.root@zimbra39-e7>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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.

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: ydirson@HIDDEN
Subject: bug#41536: Acknowledgement (uniquify can select non-unique prefix)
Message-ID: <handler.41536.B.159049781429678.ack <at> debbugs.gnu.org>
References: <1422112800.1035313346.1590497810370.JavaMail.root@zimbra39-e7>
X-Gnu-PR-Message: ack 41536
X-Gnu-PR-Package: emacs
Reply-To: 41536 <at> debbugs.gnu.org
Date: Tue, 26 May 2020 12:57:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 41536 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
41536: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41536
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#41536: uniquify can select non-unique prefix
Resent-From: Noam Postavsky <npostavs@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 May 2020 21:33:02 +0000
Resent-Message-ID: <handler.41536.B41536.159061515031569 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: ydirson@HIDDEN
Cc: 41536 <at> debbugs.gnu.org
From: Noam Postavsky <npostavs@HIDDEN>
References: <1422112800.1035313346.1590497810370.JavaMail.root@zimbra39-e7>
Date: Wed, 27 May 2020 17:32:04 -0400
In-Reply-To: <1422112800.1035313346.1590497810370.JavaMail.root@zimbra39-e7>
 (ydirson@HIDDEN's message of "Tue, 26 May 2020 14:56:50 +0200 (CEST)")
Message-ID: <857dwxt67f.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (windows-nt)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

ydirson@HIDDEN 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?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#41536: uniquify can select non-unique prefix
References: <1422112800.1035313346.1590497810370.JavaMail.root@zimbra39-e7>
Resent-From: ydirson@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 May 2020 22:24:02 +0000
Resent-Message-ID: <handler.41536.B41536.159061819712123 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Noam Postavsky <npostavs@HIDDEN>
Cc: 41536 <at> debbugs.gnu.org
Date: Thu, 28 May 2020 00:23:12 +0200 (CEST)
From: ydirson@HIDDEN
Message-ID: <521374123.1041844255.1590618192543.JavaMail.root@zimbra39-e7>
In-Reply-To: <857dwxt67f.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

----- Mail original -----
> De: "Noam Postavsky" <npostavs@HIDDEN>
> =C3=80: ydirson@HIDDEN
> Cc: 41536 <at> debbugs.gnu.org
> Envoy=C3=A9: Mercredi 27 Mai 2020 23:32:04
> Objet: Re: bug#41536: uniquify can select non-unique prefix
>=20
> ydirson@HIDDEN writes:
>=20
> > 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.
>=20
> 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-a=
ll
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 curren=
t 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 w=
as
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 c=
ase
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" v=
s. 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 lea=
ding
dirs and take the next" would fit: that would let a/x/b/y/c vs. a/b/c to re=
solve
as x/c vs. b/c.  The idea is that an outer directory is likely to carry mor=
e semantic
weight.

With more than 2 files if ambiguities arise, it is likely acceptable in man=
y cases
to keep this first dir and recurse.  Say we add a/x/t/c to the lot, that wo=
uld give
x/b/c, x/t/c, and b/c.

Does that make any sense to anyone beside me ?

Best regards,
--=20
Yann

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41536: uniquify can select non-unique prefix
References: <1422112800.1035313346.1590497810370.JavaMail.root@zimbra39-e7>
Resent-From: ydirson@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 May 2020 23:00:02 +0000
Resent-Message-ID: <handler.41536.B41536.159062034315502 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41536
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Noam Postavsky <npostavs@HIDDEN>
Cc: 41536 <at> debbugs.gnu.org
Received: via spool by 41536-submit <at> debbugs.gnu.org id=B41536.159062034315502
          (code B ref 41536); Wed, 27 May 2020 23:00:02 +0000
Received: (at 41536) by debbugs.gnu.org; 27 May 2020 22:59:03 +0000
Received: from localhost ([127.0.0.1]:50305 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1je50o-00041x-Ir
	for submit <at> debbugs.gnu.org; Wed, 27 May 2020 18:59:02 -0400
Received: from smtp6-g21.free.fr ([212.27.42.6]:44594)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ydirson@HIDDEN>) id 1je50m-00041X-6K
 for 41536 <at> debbugs.gnu.org; Wed, 27 May 2020 18:59:00 -0400
Received: from zimbra39-e7.priv.proxad.net (unknown [172.20.243.189])
 by smtp6-g21.free.fr (Postfix) with ESMTP id 9F4DE7802FE;
 Thu, 28 May 2020 00:58:58 +0200 (CEST)
Date: Thu, 28 May 2020 00:58:58 +0200 (CEST)
From: ydirson@HIDDEN
Message-ID: <908011962.1041896177.1590620338618.JavaMail.root@zimbra39-e7>
In-Reply-To: <521374123.1041844255.1590618192543.JavaMail.root@zimbra39-e7>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [91.170.159.152]
X-Mailer: Zimbra 7.2.0-GA2598 (ZimbraWebClient - FF3.0 (Linux)/7.2.0-GA2598)
X-Authenticated-User: ydirson@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


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

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 25 Aug 2020 13:49:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Aug 25 09:49:58 2020
Received: from localhost ([127.0.0.1]:60832 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kAZKo-0001u7-GY
	for submit <at> debbugs.gnu.org; Tue, 25 Aug 2020 09:49:58 -0400
Received: from mail-yb1-f175.google.com ([209.85.219.175]:42470)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <stefankangas@HIDDEN>) id 1kAZKh-0001tO-EX
 for control <at> debbugs.gnu.org; Tue, 25 Aug 2020 09:49:51 -0400
Received: by mail-yb1-f175.google.com with SMTP id a34so7175559ybj.9
 for <control <at> debbugs.gnu.org>; Tue, 25 Aug 2020 06:49:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:mime-version:date:message-id:subject:to;
 bh=xjd9M8dEFjZi+D3PnbkIUBcxlQgtg3qDV9UNSY+qrbQ=;
 b=g49ZHQ0wMN5I91QsL0dyGSjmsPYHsntvfDrHM5CZgUs1wSBIp1gKHOobdMwwLwg0Ek
 mqZSw+cww6UpOKwnGK77tShzjGFlG6sh7p+YQRUG0YZRM9OwvJOPoa1Y3bWXxI4p5Wiq
 sg242ndFdn13JJkjz6T7O0dnNKe8P6AEH8RyKLQKIhqq8+GjVD+fNfPvGKiUeqrhH0D1
 S72sI/PDiSHxtEQfg4Gvkm8Ty1K3nHzESiUm6kH0s4EIseRUh5phMsIBArfpdBzTDQte
 BB50FbBzOtYy3jGs16AfAITSckmyWCl5Zaj2UXnsgjcoREwnKI2B9QgdzA6hkTZUES2G
 He6w==
X-Gm-Message-State: AOAM532ILiHlzEOFOdnhDF+AnLupqZVGCKN2nyqjkcqC1YdT6syx/ROV
 nMAeTtuQBWBE7zLZHOrYR2GZGIU/iXIwHu9WpeeTGDmX
X-Google-Smtp-Source: ABdhPJwevmohw3XES1PyFnUM9WTIG2bU9UOZ3sxy/ukmsrCD6rR/5P77DQ+azXT7WxiXN8PQdNjYJEIVIOOiThWk9yo=
X-Received: by 2002:a25:4ed7:: with SMTP id
 c206mr15133834ybb.129.1598363385847; 
 Tue, 25 Aug 2020 06:49:45 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Tue, 25 Aug 2020 06:49:45 -0700
From: Stefan Kangas <stefan@HIDDEN>
MIME-Version: 1.0
Date: Tue, 25 Aug 2020 06:49:45 -0700
Message-ID: <CADwFkmnkx+OMJX+bknGMZh9fRa5dFu8qCOL9KSKH6wpFFS8OYw@HIDDEN>
Subject: 
To: control <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 2.5 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  severity 41536 wishlist thanks 
 Content analysis details:   (2.5 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (stefankangas[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
 mail domains are different
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.219.175 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.219.175 listed in wl.mailspike.net]
 2.0 BLANK_SUBJECT          Subject is present but empty
 0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay
 lines
 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
 EnvelopeFrom freemail headers are different
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.5 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  severity 41536 wishlist thanks 
 
 Content analysis details:   (1.5 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.219.175 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.219.175 listed in list.dnswl.org]
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (stefankangas[at]gmail.com)
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  2.0 BLANK_SUBJECT          Subject is present but empty
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
  0.0 UNPARSEABLE_RELAY      Informational: message has unparseable relay
                             lines
  0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                             EnvelopeFrom freemail headers are
                             different

severity 41536 wishlist
thanks

Last modified: Tue, 25 Aug 2020 14:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.