From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A couple of things that I think should be in byte bytecode meta comments Date: Fri, 22 Dec 2017 22:25:22 +0200 Message-ID: <83h8sildcd.fsf@gnu.org> References: <83o9mqlin0.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1513974315 11490 195.159.176.226 (22 Dec 2017 20:25:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 22 Dec 2017 20:25:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rocky Bernstein Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 22 21:25:11 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eSTsS-0002Qj-2f for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 21:25:08 +0100 Original-Received: from localhost ([::1]:37389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSTuQ-0000jN-9p for ged-emacs-devel@m.gmane.org; Fri, 22 Dec 2017 15:27:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSTtR-0000bb-B0 for emacs-devel@gnu.org; Fri, 22 Dec 2017 15:26:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eSTt4-0001Uv-Kw for emacs-devel@gnu.org; Fri, 22 Dec 2017 15:26:09 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59049) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eSTsh-00011P-9I; Fri, 22 Dec 2017 15:25:23 -0500 Original-Received: from [176.228.60.248] (port=2839 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eSTsg-0005OD-L0; Fri, 22 Dec 2017 15:25:23 -0500 In-reply-to: (message from Rocky Bernstein on Fri, 22 Dec 2017 13:49:06 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221352 Archived-At: > From: Rocky Bernstein > Date: Fri, 22 Dec 2017 13:49:06 -0500 > Cc: emacs-devel@gnu.org > > Now as to the portability. Yes, if the file is run on another system, the path isn't exact. But it does give some > idea of what we are talking as you git closer to the bottom of the path and that may be helpful. > > Consider cases where I have a stable and development branch and then install into say > /usr/local/share/emacs/lisp. Even though the top-level directories are not the same, it still is useful to know > where in the source code tree (whether on my system or not). I guess I'm not following you. On my system, there are 60 files whose absolute file names end in lisp/emacs-lisp/bytecomp.el. (And my equivalent of your /usr/local/share/emacs is populated with files that came from a tree which is not the stable nor the development branches.) Some of these 60 files come from the same versions of Emacs, some from different versions. How can a signature that records the absolute file name help in distinguishing between bytecomp.elc's that were produced from the same or identical files, and those which were produced from different, i.e. "incompatible" files? What am I missing here? > And finally there will be cases where the path is exact. Too few to rely on, what with today's practice of installing pre-built packages instead of building from sources on each end-user system. > In sum, just because sometimes it doesn't work out, doesn't mean it will be totally meaningless all the time. > And I prefer "sometimes useful" to no information, however accurate that is. I'm saying that the minuscule amount of times it will work will drown in the sea of times it won't. Worse, when it "doesn't work", it will many times produce a false alarm: the file name is different, but the contents was identical. How will you distinguish between true negatives and false negatives? Without a means to distinguish between them, this feature will be worse then useless: it will be an absolute nuisance.