From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#55778: 29.0.50; [PATCH] M-. into a .gz; we've all been there. Date: Fri, 03 Jun 2022 18:45:48 +0800 Message-ID: <87sfom3u03.fsf@yahoo.com> References: <87k09yw9ao.fsf@dick> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28287"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: 55778@debbugs.gnu.org To: dick.r.chiang@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 03 12:47:27 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nx4pz-00076h-8I for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Jun 2022 12:47:27 +0200 Original-Received: from localhost ([::1]:34142 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nx4px-0000TD-Lc for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Jun 2022 06:47:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60016) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nx4pa-0000RU-Gr for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2022 06:47:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33227) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nx4pZ-00062R-VB for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2022 06:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nx4pZ-0002o0-U0 for bug-gnu-emacs@gnu.org; Fri, 03 Jun 2022 06:47:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 03 Jun 2022 10:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55778 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 55778-submit@debbugs.gnu.org id=B55778.165425317010726 (code B ref 55778); Fri, 03 Jun 2022 10:47:01 +0000 Original-Received: (at 55778) by debbugs.gnu.org; 3 Jun 2022 10:46:10 +0000 Original-Received: from localhost ([127.0.0.1]:55357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nx4oj-0002mw-Ps for submit@debbugs.gnu.org; Fri, 03 Jun 2022 06:46:10 -0400 Original-Received: from sonic308-56.consmr.mail.ne1.yahoo.com ([66.163.187.31]:39821) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nx4oh-0002mB-95 for 55778@debbugs.gnu.org; Fri, 03 Jun 2022 06:46:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654253160; bh=QbQ5qBamlucpThEetdDNk9ifm5JKHcppnSeQlhAkbTI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Z43qPrLM2c9iE0ZUwf/4K6za5DHJ7MqMdO6EHc5dPXrKEPiDU8YbqG2LQ7QOFbgCyvOlZpsgK2RPevdLhiDNKfMAuQBoSHXWBykfSVODR5nlTUVG1gC8aWKovniEWgHwZUPUuNWWqWheuSbDZlgw1PFgHFr/7fd4Z4Qd8PPvGJ6n0+u8bPRV9LT97+PGX5vAKlaTUYMhaO5M3zCgnk1bz0/3Ii3bsPmkgXV+IcVrhjIipDiZeLnZmCZrSXzWpLX3dcl9jRjvwhp9ZAQqMlDNMYrl4xceGv6qPYRj0E/XlynVVxdwJYbuDLIhWq2UGdza4TAKsgCP+dHCz18LX19INw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1654253160; bh=9Z7i/FoigajMASh0/mzO9O+dwFHM+oORff7CqzI4VKf=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=F/cB+M4dXi2VCeYlcchS/3kErjRH3rVzNifGmAfvEDnepxPFdn38BCUWp+1nM088Es8WeBDk9ZTdx3mKePDRuTV3xmHnyEWwOp1l7txZOlEBG3WY2r0rF4IiVvm/i14avJax82STjyetwokMoMLwaiIpLJdIfs/bh6HLnhudQwKdXGBb/8AlUn7UZ611k/aRJMi7CalmomIwwfBn5PWLXL2XcdM/l8ukjtxiRPH7iBs9yA6PmleNV/jP5ScjUwK2ffg5p9A83W9JDM+BsMdALcVCJ/BfPlr0NUzij28b40CEOprlC4SRcr7UC6r9uTa/uWe/5klZe3bwSSCSoCHHNw== X-YMail-OSG: Hasp0toVM1mlgaUwpDYY9I4fokmk6n.jszT9hWd_CUeTfXRXDO08r4imfkgCQqP sRALFUO0rRHew6E0aRxG.SsylcnL_ZqtY1tTG37NkkpnQzecLqGSqVt6qjBrwL4582ToXYSvTCQW 6xeD_KWLwUcgtuNUn9Uy3GEWKLKi0ssxmbKydU3EkPHqkIF2E0ZUTWKsZnkUwXEzlPV00noS9JQq i_Z2Rds22pobtTGQpAhQukrV5yIVYqEg4c9bd.hWcf0Pi9DBmyr1xe6LcsvgSnkxIE47.BGvgdgc RZLFz1m7KK3hSuu27lGVx.hPN5IzunJJu.KKDiOq.yjbvrc1rWZp71PuBcD0yERDLqo3NOuwEmeP IKm2QzjHQSaM9lTibqDhYpVEeFD1tkudtRt09dBFGrztWvTdjFZuVNVNHraWI_4unw8EGhLggdbh tFn2krV.C_Et4nheA8qIJPtMWwpAU7izfUGakP62o29VlTOnFiS_CrhWNs2MrnX7x8X_ivdWYmZ3 pzBWEEeJHkrl_5oHuSQhhg0CwPeZO_9KTod8NTD473bpKJ2_kOFE0a4PO0J5NWNdF6KvkeSxT_IO 6T9ZpZms1FQNaVRtMu9uAnGtMOIxLQ_zDO6ZpLjFaVRtWfDLh2OgTZGms9IRV1z1wzMokLGVIYot 6ZIlhoOcDjD733ExX.VECEylIKCqQrMWgekLyLxiAsFwo1ku.xd8gPvTk5EoV8U4CkcvTwVB4zK0 CWApQfGWovyAmGc.M6C9rrPyIuHeSGajEHo1KBJ5pON_Al_4Ci7tv2DmAUa14KzO4s64MTtRrhDF NbRp2AlA4CyDYinxcd0WDrSDQXZ045nD5MiBu1XEUy X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 3 Jun 2022 10:46:00 +0000 Original-Received: by hermes--canary-production-sg3-5f7658c994-r59gj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 57d66d6b0bd4b1fed042a6977e70aac0; Fri, 03 Jun 2022 10:45:53 +0000 (UTC) In-Reply-To: <87k09yw9ao.fsf@dick> (dick r. chiang's message of "Fri, 03 Jun 2022 02:27:59 -0400") X-Mailer: WebService/1.1.20225 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:233600 Archived-At: Thanks, but this does not look acceptable, if not for anything else, then for the simple fact that so much text (comments and doc strings) was changed for the worse. dick.r.chiang@gmail.com writes: > * lisp/emacs-lisp/find-func.el (find-function-regexp-alist): > Was crashing on this missing entry in find-function-regexp-alist. > (find-function-C-source-directory): Style. > (find-function-C-source): Style. > (find-function-search-for-symbol): English. > * lisp/help-fns.el (help-C-file-name): English. "English." "Style." and "Was crashing on this missing entry in find-function-regexp-alist" do not describe what changed, and why it was changed. > +LIBRARY can be an absolute or relative path." Say "file name" instead of "path". > -KIND should be `var' for a variable or `subr' for a subroutine. > -If we can't find the file name, nil is returned." > +KIND should be 'var for a variable or 'subr for a subroutine. If > +we can't find the file name, nil is returned." Whitespace and formatting change. > +(defcustom xref-prefer-source-directory nil > + "If non-nil, jump to the file in `source-directory' that > +corresponds to the target." > + :type 'boolean > + :version "29.1") > + Did implementing this feature really require so many changes, in project.el, elisp-mode.el, help-fns.el, help-mode.el, emacs.c, and lread.c? > DEFVAR_LISP ("installation-directory", Vinstallation_directory, > - doc: /* A directory within which to look for the `lib-src' and `etc' directories. > -In an installed Emacs, this is normally nil. It is non-nil if > -both `lib-src' (on MS-DOS, `info') and `etc' directories are found > -within the variable `invocation-directory' or its parent. For example, > -this is the case when running an uninstalled Emacs executable from its > -build directory. */); > + doc: /* Should have been named build-directory. > +Counter-intuitively, this variable is nil when Emacs is invoked from > +its `make install` executable. It normally takes on the value of > +`source-directory' when Emacs is invoked from its within-repo `make` > +executable. Its primary use is locating the lib-src and etc > +subdirectories of the build. Not to be confused with > +`installed-directory'. */); > Vinstallation_directory = Qnil; Useless doc change. > -/* Return the default load-path, to be used if EMACSLOADPATH is unset. > - This does not include the standard site-lisp directories > - under the installation prefix (i.e., PATH_SITELOADSEARCH), > - but it does (unless no_site_lisp is set) include site-lisp > - directories in the source/build directories if those exist and we > - are running uninstalled. > - > - Uses the following logic: > - If !will_dump: Use PATH_LOADSEARCH. > - The remainder is what happens when dumping is about to happen: > - If dumping, just use PATH_DUMPLOADSEARCH. > - Otherwise use PATH_LOADSEARCH. > - > - If !initialized, then just return PATH_DUMPLOADSEARCH. > - If initialized: > - If Vinstallation_directory is not nil (ie, running uninstalled): > - If installation-dir/lisp exists and not already a member, > - we must be running uninstalled. Reset the load-path > - to just installation-dir/lisp. (The default PATH_LOADSEARCH > - refers to the eventual installation directories. Since we > - are not yet installed, we should not use them, even if they exist.) > - If installation-dir/lisp does not exist, just add > - PATH_DUMPLOADSEARCH at the end instead. > - Add installation-dir/site-lisp (if !no_site_lisp, and exists > - and not already a member) at the front. > - If installation-dir != source-dir (ie running an uninstalled, > - out-of-tree build) AND install-dir/src/Makefile exists BUT > - install-dir/src/Makefile.in does NOT exist (this is a sanity > - check), then repeat the above steps for source-dir/lisp, site-lisp. */ > +/* Dig toplevel LOAD-PATH out of epaths.h. */ Comment deleted and replaced with something much less meaningful. > static Lisp_Object > load_path_default (void) > { > if (will_dump_p ()) > - /* PATH_DUMPLOADSEARCH is the lisp dir in the source directory. > - We used to add ../lisp (ie the lisp dir in the build > - directory) at the front here, but that should not be > - necessary, since in out of tree builds lisp/ is empty, save > - for Makefile. */ > + /* PATH_DUMPLOADSEARCH is the lisp dir in the source directory. */ > return decode_env_path (0, PATH_DUMPLOADSEARCH, 0); > > - Lisp_Object lpath = Qnil; > - > - lpath = decode_env_path (0, PATH_LOADSEARCH, 0); > + Lisp_Object lpath = decode_env_path (0, PATH_LOADSEARCH, 0); > > + /* Counter-intuitively Vinstallation_directory is nil for > + invocations of the `make install` executable, and is > + Vsource_directory for invocations of the within-repo `make` > + executable. > + */ > if (!NILP (Vinstallation_directory)) > { > - Lisp_Object tem, tem1; > - > - /* Add to the path the lisp subdir of the installation > - dir, if it is accessible. Note: in out-of-tree builds, > - this directory is empty save for Makefile. */ > - tem = Fexpand_file_name (build_string ("lisp"), > - Vinstallation_directory); > - tem1 = Ffile_accessible_directory_p (tem); > - if (!NILP (tem1)) > - { > - if (NILP (Fmember (tem, lpath))) > - { > - /* We are running uninstalled. The default load-path > - points to the eventual installed lisp directories. > - We should not use those now, even if they exist, > - so start over from a clean slate. */ > - lpath = list1 (tem); > - } > - } > - else > - /* That dir doesn't exist, so add the build-time > - Lisp dirs instead. */ > - { > - Lisp_Object dump_path = > - decode_env_path (0, PATH_DUMPLOADSEARCH, 0); > - lpath = nconc2 (lpath, dump_path); > - } > - > - /* Add site-lisp under the installation dir, if it exists. */ > - if (!no_site_lisp) > + Lisp_Object tem = Fexpand_file_name (build_string ("lisp"), > + Vinstallation_directory), > + tem1 = Ffile_accessible_directory_p (tem); > + > + if (NILP (tem1)) > + /* Use build-time dirs instead. */ > + lpath = nconc2 (lpath, decode_env_path (0, PATH_DUMPLOADSEARCH, 0)); > + else if (NILP (Fmember (tem, lpath))) > + /* Override the inchoate LOAD-PATH. */ > + lpath = list1 (tem); > + > + /* Add the within-repo site-lisp (unusual). */ > + if (! no_site_lisp) > { > tem = Fexpand_file_name (build_string ("site-lisp"), > Vinstallation_directory); > tem1 = Ffile_accessible_directory_p (tem); > - if (!NILP (tem1)) > - { > - if (NILP (Fmember (tem, lpath))) > - lpath = Fcons (tem, lpath); > - } > + if (! NILP (tem1) && (NILP (Fmember (tem, lpath)))) > + lpath = Fcons (tem, lpath); > } > > - /* If Emacs was not built in the source directory, > - and it is run from where it was built, add to load-path > - the lisp and site-lisp dirs under that directory. */ > - > if (NILP (Fequal (Vinstallation_directory, Vsource_directory))) > { > - Lisp_Object tem2; > - > + /* An out-of-tree build (unusual). */ > tem = Fexpand_file_name (build_string ("src/Makefile"), > Vinstallation_directory); > - tem1 = Ffile_exists_p (tem); > + tem1 = Fexpand_file_name (build_string ("src/Makefile.in"), > + Vinstallation_directory); > > /* Don't be fooled if they moved the entire source tree > AFTER dumping Emacs. If the build directory is indeed > different from the source dir, src/Makefile.in and > src/Makefile will not be found together. */ > - tem = Fexpand_file_name (build_string ("src/Makefile.in"), > - Vinstallation_directory); > - tem2 = Ffile_exists_p (tem); > - if (!NILP (tem1) && NILP (tem2)) > + if (! NILP (Ffile_exists_p (tem)) && NILP (Ffile_exists_p (tem1))) > { > tem = Fexpand_file_name (build_string ("lisp"), > Vsource_directory); > - > if (NILP (Fmember (tem, lpath))) > lpath = Fcons (tem, lpath); > - > - if (!no_site_lisp) > + if (! no_site_lisp) > { > tem = Fexpand_file_name (build_string ("site-lisp"), > Vsource_directory); > - tem1 = Ffile_accessible_directory_p (tem); > - if (!NILP (tem1)) > - { > - if (NILP (Fmember (tem, lpath))) > - lpath = Fcons (tem, lpath); > - } > + if (! NILP (tem) && (NILP (Fmember (tem, lpath)))) > + lpath = Fcons (tem, lpath); > } > } > - } /* Vinstallation_directory != Vsource_directory */ > - > - } /* if Vinstallation_directory */ > + } > + } > > return lpath; > } What you did was change the behavior of code that has worked well enough for decades. Is that really needed to make finding a definition prefer the source directory to the compressed Lisp code? Not to mention that you can avoid jumping into the compressed source by specifying --without-compress-install at configure time. > + bool use_loadpath = ! will_dump_p (); > > if (use_loadpath && egetenv ("EMACSLOADPATH")) > { > @@ -5268,10 +5205,9 @@ init_lread (void) > load_path_check (default_lpath); > > /* Add the site-lisp directories to the front of the default. */ > - if (!no_site_lisp && PATH_SITELOADSEARCH[0] != '\0') > + if (! no_site_lisp && PATH_SITELOADSEARCH[0] != '\0') > { > - Lisp_Object sitelisp; > - sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0); > + Lisp_Object sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0); > if (! NILP (sitelisp)) > default_lpath = nconc2 (sitelisp, default_lpath); > } > @@ -5286,7 +5222,7 @@ init_lread (void) > Vload_path = CALLN (Fappend, Vload_path, > NILP (elem) ? default_lpath : list1 (elem)); > } > - } /* Fmemq (Qnil, Vload_path) */ > + } > } > else > { > @@ -5299,11 +5235,11 @@ init_lread (void) > load_path_check (Vload_path); > > /* Add the site-lisp directories at the front. */ > - if (!will_dump_p () && !no_site_lisp && PATH_SITELOADSEARCH[0] != '\0') > + if (! will_dump_p () && !no_site_lisp && PATH_SITELOADSEARCH[0] != '\0') > { > - Lisp_Object sitelisp; > - sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0); > - if (! NILP (sitelisp)) Vload_path = nconc2 (sitelisp, Vload_path); > + Lisp_Object sitelisp = decode_env_path (0, PATH_SITELOADSEARCH, 0); > + if (! NILP (sitelisp)) > + Vload_path = nconc2 (sitelisp, Vload_path); > } > } Whitespace changes, comment aimlessly deleted. > + DEFVAR_LISP ("installed-directory", Vinstalled_directory, > + doc: /* Install path of built-in lisp libraries. > +This directory contains the `etc`, `lisp`, and `site-lisp` > +installables, and is determined at configure time in the epaths-force > +make target. Not to be confused with the legacy > +`installation-directory' nor `invocation-directory'. */); > + Vinstalled_directory > + = Fexpand_file_name (build_string ("../"), > + Fcar (decode_env_path (0, PATH_LOADSEARCH, 0))); Why is yet another one of these variables needed? And was this change tested on every possible installation type, such as an NS self-contained bundle or MS-DOS?