GNU bug report logs - #71817
29.3; Sub-directory handling of ELPA package

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

Received: (at 71817) by debbugs.gnu.org; 30 Jun 2024 03:27:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 29 23:27:10 2024
Received: from localhost ([127.0.0.1]:54308 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sNlDa-0005j1-Lq
	for submit <at> debbugs.gnu.org; Sat, 29 Jun 2024 23:27:10 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17871)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>)
 id 1sNlDX-0005ij-U8; Sat, 29 Jun 2024 23:27:08 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B03504421B1;
 Sat, 29 Jun 2024 23:27:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719718019;
 bh=fkazdDzLb02Em6Xla8Dyesu1p0HVxhmsxwY5DOZ5VZo=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=ErwvOrEmnKLsUCBDy3Iz274ZDWbVVKjm4ZIKUTbVHTIC/5vIS72uZAdZzECE1rZGy
 rOOUd8Xq9PpHh0uC8AdnP2LDucHfWlvymQJb/EcdJ9V85BiniIVfy8To/rPkewnIFV
 wunpiq5tlaiMUIKojO0quS/YcA5UioK9jObC9DuDXC0QG76RBt/ivM3mBYDHHoQaKp
 DXPDRgwjZ8jBYQPIQkGl6HmzKUkE+JRmr7RbzTNlNNppefpWo+21DzGukbAJZwy3TY
 iCkvN3NT1a2Od5T1w5H7dgbuGhvsiaXaT5IfZlDQHCXaGQvU+Jw0dJizpqdrtp8KoT
 f24IGJD/9HxPg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DF8D544200F;
 Sat, 29 Jun 2024 23:26:59 -0400 (EDT)
Received: from pastel (unknown [45.72.245.253])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AFCB6120568;
 Sat, 29 Jun 2024 23:26:59 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Xiyue Deng <manphiz@HIDDEN>
Subject: Re: bug#71817: 29.3; Sub-directory handling of ELPA package
In-Reply-To: <877ce75nqv.fsf@HIDDEN> (Xiyue Deng's message of "Sat,
 29 Jun 2024 16:32:24 -0700")
Message-ID: <jwved8fru2y.fsf-monnier+emacs@HIDDEN>
References: <875xtt8jdm.fsf@HIDDEN>
 <jwvsewxw6w1.fsf-monnier+emacs@HIDDEN>
 <877ce75nqv.fsf@HIDDEN>
Date: Sat, 29 Jun 2024 23:26:58 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.369 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71817
Cc: 71817 <at> debbugs.gnu.org
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: -3.3 (---)

> Thanks for the explanations and for exploring options to load sources in
> sub-directories without recursive loading by default.  I take that the
> current status - byte-compile recursively, only add source root path to
> `load-path' - will continue to be the path forward.

Yes.

> For now, it makes sense that loading sources from sub-directories
> requires some manual `load-path' handling.  Maybe when using
> sub-directories to organize source files becomes more common upstream
> may consider adding some convenient functions/macros to make it easier,
> but it will be for the future.

The direction I'd like to move into is to do fewer things automatically
when installing Emacs and instead move the work to the moment when we
build the tarball.


        Stefan

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

Received: (at 71817) by debbugs.gnu.org; 29 Jun 2024 23:33:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 29 19:33:35 2024
Received: from localhost ([127.0.0.1]:54139 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sNhZW-0005MR-Nx
	for submit <at> debbugs.gnu.org; Sat, 29 Jun 2024 19:33:35 -0400
Received: from mail-il1-f172.google.com ([209.85.166.172]:50394)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <manphiz@HIDDEN>) id 1sNhZV-0005ME-1b
 for 71817 <at> debbugs.gnu.org; Sat, 29 Jun 2024 19:33:33 -0400
Received: by mail-il1-f172.google.com with SMTP id
 e9e14a558f8ab-375858224adso8729745ab.0
 for <71817 <at> debbugs.gnu.org>; Sat, 29 Jun 2024 16:33:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719703947; x=1720308747; darn=debbugs.gnu.org;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=ZgUI8tLlt5dqnKrCdWYh755caCTxw7fhDXnPvb3wOkw=;
 b=D7gh6RDB/R5CkyHLnx3BFebgt+i2560AtjORojIltrXb5ZcT7d3KnNvH9Ty1CfhNZh
 IeBvrBT6KQFDsLjw3dMjvocCSYmXSQHD4eNKlEvXwi4dp6RlYB0Jpk+VBdX7iWBdOXVJ
 a/GOy/LCrJXSkjbvnKjlEwh3+uiizc1DeZqOgZLvT1mh3YPTF5uJHSKsChjh76eYdRke
 qBnN/xPvTvM1UD7hmCqNFT5eW2svAmvoPP95RTPQC3OlRJDc9obBJM9864pJmPv1G7op
 e5b86eWX0GNA8vNfY3QfB8GWEmhxOfBoYkgRSWMXL/4fqYeRFroL8Q4jTGx+l9FjTTY4
 j/1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719703947; x=1720308747;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=ZgUI8tLlt5dqnKrCdWYh755caCTxw7fhDXnPvb3wOkw=;
 b=k8NtSKg9DHQzZ8cvogEBHiU2aAHK5/DDBeDg+jm6qM7md72Ty3CsitTNkNzZivxsF6
 de9i4FIbYzfQ0l2uzZJIoKLbaFCE6s8VoSZ8qXXveukEPmDWOF3rhT7s3l9Yr8zYJB0l
 Qz5UNy39sW1WSjKeizgy2z8z6r05t1RP4vnFc+A8v/fDOUJi7J1S2BJf6iyJ6rmKuEh0
 jRM7u6LN5+W6VdE/UsMo7Zk2nlzeLUcj+bUc25AZgldxals5hbPpk0F0tFa6LzBFsGW5
 ijoUC294J5EmCX7i08flhcjYf8OCmCMQyffOhaYUoRNPUIJNQmvh1xspw7KOlc7Y8B81
 49IQ==
X-Gm-Message-State: AOJu0YyuRKye4FyFZvBBaP491MDyCBCcr6N5sZQptdPqP6X3Xl29NwNM
 jLEHYEv3H59KrL8MSxiDUFvHfK94vk4SoYKvkJo1ZRBhq7NKTfWThDux+5SDyEcD8Q==
X-Google-Smtp-Source: AGHT+IHSyI9UUuoxuH2E8FvtwsDHf8jXFQ+qB9kh/H/bwSJWixDBkj4SYsKQEhCGXWQbSIdbxuCaSw==
X-Received: by 2002:a05:6e02:b2c:b0:376:1cf6:6be4 with SMTP id
 e9e14a558f8ab-37cd0ee0199mr25938255ab.14.1719703945441; 
 Sat, 29 Jun 2024 16:32:25 -0700 (PDT)
Received: from debian-hx90 ([2603:8000:a400:cdc:9e7a:da57:565:c768])
 by smtp.gmail.com with ESMTPSA id
 d9443c01a7336-1fac10d20c1sm37318025ad.30.2024.06.29.16.32.24
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 29 Jun 2024 16:32:25 -0700 (PDT)
From: Xiyue Deng <manphiz@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#71817: 29.3; Sub-directory handling of ELPA package
In-Reply-To: <jwvsewxw6w1.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Fri, 28 Jun 2024 09:26:55 -0400")
References: <875xtt8jdm.fsf@HIDDEN>
 <jwvsewxw6w1.fsf-monnier+emacs@HIDDEN>
Date: Sat, 29 Jun 2024 16:32:24 -0700
Message-ID: <877ce75nqv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 71817
Cc: 71817 <at> debbugs.gnu.org
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 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>> Currently as observed, ELPA packages only get their root path added to
>> `load-path', but source code in sub-directories will still get
>> byte-compiled.  That is, for an ELPA package elpafoo with a nested
>> sub-directory of the following structure (installed through package.el):
>
> The recursive compilation is somewhat of an "accident": it was the
> easiest to implement (and seemed like a good idea anyway).
>
> The `load-path` behavior is conscious: it's easy for a package to add
> more subdirectories to the `load-path` but it would be much harder to
> remove undesired ones.  [ And of course, the current behavior is also
> the easiest one to implement.  ]
>
>> If this is not yet a policy, I wonder whether this will be the path
>> forward for `load-path' handling.
>
> In `elpafoo.el`, include something like:
>
>     ;;;###autoload
>     (add-to-list 'load-path
>                  (expand-file-name
>                   "elpabar" (file-name-directory load-file-name)))
>
> This assumes that you want `elpabar` to be in your `load-path` right
> from the start (i.e. that an entry point to your package is in the
> `elpabar` subdirectory).  If `elpabar` can only ever be used from code
> that's in the `elpafoo` directory, there are other options (such as
> `(require 'elpabar/elpabar)` or using an auxiliary `elpafoo-loaddefs.el`
> which you load when `elpafoo.el` is loaded, ...
>
>> I see some pros of adding sub-directories recursively,
>
> I don't.  Most of the packages which use subdirectories have a complex
> enough layout that some of those directories should not be in
> `load-path`: it's better to let them add entries "manually" at the
> appropriate time than to try and do it automatically.
>
> The more real problem is that the way `elpafoo-autoloads.el` is created
> does *not* scan ELisp files in subdirectories.  The way this is handled
> typically in that the ELPA tarball comes with its own
> `elpabar/elpabar-autoloads.el` file and `elpafoo.el` then needs to
> contain something like
>
>     ;;;###autoload
>     (require 'elpabar/elpabar-autoloads)
>
> The main downside here is that the current elpa.gnu.org scripts don't
> know how to build such a `elpabar/elpabar-autoloads.el`, so you either
> need to store it in the Git (which is ugly since it's a generated file),
> or use an ad-hoc `:make` rule.
>
> IMO we should change the ELPA protocol so that the
> `elpafoo-autoloads.el` is not created during installation but is instead
> included in the tarball, so it can be generated any way we like.
>
>
>         Stefan
>

Thanks for the explanations and for exploring options to load sources in
sub-directories without recursive loading by default.  I take that the
current status - byte-compile recursively, only add source root path to
`load-path' - will continue to be the path forward.

For now, it makes sense that loading sources from sub-directories
requires some manual `load-path' handling.  Maybe when using
sub-directories to organize source files becomes more common upstream
may consider adding some convenient functions/macros to make it easier,
but it will be for the future.

Thanks again!

-- 
Xiyue Deng

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

Received: (at 71817) by debbugs.gnu.org; 28 Jun 2024 13:27:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 28 09:27:07 2024
Received: from localhost ([127.0.0.1]:44887 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sNBd5-00038Z-4L
	for submit <at> debbugs.gnu.org; Fri, 28 Jun 2024 09:27:07 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36853)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1sNBd2-000388-13
 for 71817 <at> debbugs.gnu.org; Fri, 28 Jun 2024 09:27:05 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 32E8480AD4;
 Fri, 28 Jun 2024 09:26:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1719581216;
 bh=PvdsKOaAWEKg4ABGxugXhab6RWy4Kwod21fLEyJ5rj8=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=ilGZgvee2SKGsd1SI+dMtsL1gB7a2R1PmAo0JDp7MgHE/t1a+go1QsFD/5IKg33jg
 g2x9zu5nVpmOajbEpb2jFJ497wBxNXl7T4U5xs9RF5L1Ql5B6p+wlhPx6I7hI9zp4b
 6HNaqzipvdVmG4ObkXaLI37+OfPb0yhVJD7LenIBXhZEzvo1LFmANJpadZGgl57kKY
 Jf8z/MUOVWuGcl4abN7E6iI8UFYJev8sLf/8qvFkpRcCpOOPkyTnHkDdsHvbnR3feP
 ZAEFSOfYbsI+GLWftmQ/c+1bGgs5JULiju77kf9oMv94g1F1cHQp1d7ewIl5fao4sn
 AEX1CbAIAypzA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AB17480292;
 Fri, 28 Jun 2024 09:26:56 -0400 (EDT)
Received: from pastel (unknown [45.72.245.253])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 86697120262;
 Fri, 28 Jun 2024 09:26:56 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Xiyue Deng <manphiz@HIDDEN>
Subject: Re: bug#71817: 29.3; Sub-directory handling of ELPA package
In-Reply-To: <875xtt8jdm.fsf@HIDDEN> (Xiyue Deng's message of "Fri,
 28 Jun 2024 03:13:57 -0700")
Message-ID: <jwvsewxw6w1.fsf-monnier+emacs@HIDDEN>
References: <875xtt8jdm.fsf@HIDDEN>
Date: Fri, 28 Jun 2024 09:26:55 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [gnu.org]
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71817
Cc: 71817 <at> debbugs.gnu.org
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: -3.3 (---)

> Currently as observed, ELPA packages only get their root path added to
> `load-path', but source code in sub-directories will still get
> byte-compiled.  That is, for an ELPA package elpafoo with a nested
> sub-directory of the following structure (installed through package.el):

The recursive compilation is somewhat of an "accident": it was the
easiest to implement (and seemed like a good idea anyway).

The `load-path` behavior is conscious: it's easy for a package to add
more subdirectories to the `load-path` but it would be much harder to
remove undesired ones.  [ And of course, the current behavior is also
the easiest one to implement.  ]

> If this is not yet a policy, I wonder whether this will be the path
> forward for `load-path' handling.

In `elpafoo.el`, include something like:

    ;;;###autoload
    (add-to-list 'load-path
                 (expand-file-name
                  "elpabar" (file-name-directory load-file-name)))

This assumes that you want `elpabar` to be in your `load-path` right
from the start (i.e. that an entry point to your package is in the
`elpabar` subdirectory).  If `elpabar` can only ever be used from code
that's in the `elpafoo` directory, there are other options (such as
`(require 'elpabar/elpabar)` or using an auxiliary `elpafoo-loaddefs.el`
which you load when `elpafoo.el` is loaded, ...

> I see some pros of adding sub-directories recursively,

I don't.  Most of the packages which use subdirectories have a complex
enough layout that some of those directories should not be in
`load-path`: it's better to let them add entries "manually" at the
appropriate time than to try and do it automatically.

The more real problem is that the way `elpafoo-autoloads.el` is created
does *not* scan ELisp files in subdirectories.  The way this is handled
typically in that the ELPA tarball comes with its own
`elpabar/elpabar-autoloads.el` file and `elpafoo.el` then needs to
contain something like

    ;;;###autoload
    (require 'elpabar/elpabar-autoloads)

The main downside here is that the current elpa.gnu.org scripts don't
know how to build such a `elpabar/elpabar-autoloads.el`, so you either
need to store it in the Git (which is ugly since it's a generated file),
or use an ad-hoc `:make` rule.

IMO we should change the ELPA protocol so that the
`elpafoo-autoloads.el` is not created during installation but is instead
included in the tarball, so it can be generated any way we like.


        Stefan

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

Received: (at 71817) by debbugs.gnu.org; 28 Jun 2024 11:19:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 28 07:19:39 2024
Received: from localhost ([127.0.0.1]:44795 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sN9dj-0005Vi-1d
	for submit <at> debbugs.gnu.org; Fri, 28 Jun 2024 07:19:39 -0400
Received: from eggs.gnu.org ([209.51.188.92]:53160)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1sN9dg-0005VU-Ge
 for 71817 <at> debbugs.gnu.org; Fri, 28 Jun 2024 07:19:37 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1sN9da-00063c-Tp; Fri, 28 Jun 2024 07:19:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=2r9Yys1X/PK+5RyUqsMoq8hcgHKj8AolZg/3HEWOWkM=; b=EZ/4u6CCPXMe
 W7+8kGo6Ve2+T91xGy6L7ciF9IKWRh6uLm8s7txqALTJSoGDwtxOYKVLAE1rfu8+OEYCbwPv0N4UO
 fHvFS2nfJf10HHBQn4906eCCbpmBKpXyv0p1w0D5h4LKQAt9BhR0Uh5s4VKTELduWVJNPssjMMw0o
 h+eR/GeI1629ETzXSltSkVhsHplINLP199wzZsp6CjuJvDLcJJ5sOyr9l99kDlAS1+1JIw5fYLA23
 U6HcY2iO6UGo2eYafMZW2oaDxV8NuUAXFRocqV0YOvUcps5ceJXpmy6sz5PI3i/O8bPhNuo+O+jfI
 HoMWAzNyADnilk85DpkZFA==;
Date: Fri, 28 Jun 2024 14:19:28 +0300
Message-Id: <86bk3l48n3.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Xiyue Deng <manphiz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <875xtt8jdm.fsf@HIDDEN> (message from Xiyue Deng on Fri, 
 28 Jun 2024 03:13:57 -0700)
Subject: Re: bug#71817: 29.3; Sub-directory handling of ELPA package
References: <875xtt8jdm.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 71817
Cc: 71817 <at> debbugs.gnu.org
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: -3.3 (---)

> From: Xiyue Deng <manphiz@HIDDEN>
> Date: Fri, 28 Jun 2024 03:13:57 -0700
> 
> I'm opening a bug to continue the discussion from the emacs-devel
> mailing list thread[1].
> 
> TL;DR I would like to understand how upstream would like to handle
> sub-directories with ELisp source files as to whether to add them to
> `load-path' recursively or not to determine the path forward for source
> code organization.
> 
> Currently as observed, ELPA packages only get their root path added to
> `load-path', but source code in sub-directories will still get
> byte-compiled.  That is, for an ELPA package elpafoo with a nested
> sub-directory of the following structure (installed through package.el):
> 
> ,----
> | ~/.config/emacs/elpa/elpafoo/
> | ~/.config/emacs/elpa/elpafoo/elpafoo.el
> | ~/.config/emacs/elpa/elpafoo/elpabar
> | ~/.config/emacs/elpa/elpafoo/elpabar/elpabar.el
> `----
> 
> only `~/.config/emacs/elpa/elpafoo' is added to `load-path', while both
> elpafoo.el and elpabar.el will get byte-compiled.  Currently I don't
> seem to find where this behavior is documented, so do give me a pointer
> if it exists.
> 
> If this is not yet a policy, I wonder whether this will be the path
> forward for `load-path' handling.  I see some pros of adding
> sub-directories recursively, such as better source code organization so
> that not all source code files need to reside in the root directory.
> However, the downside is also obvious, such as unnecessary loading of
> test sources as Michael pointed out in [2], or loading vendored code
> that could cause conflicts (as I observed in the case of auctex), etc.
> 
> So, what would be the upstream or package.el maintainers' opinions on
> how this should be handled?
> 
> Thanks in advance.
> 
> [1] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00658.html
> [2] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01039.html

Adding Stefan.

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

Received: (at submit) by debbugs.gnu.org; 28 Jun 2024 10:14:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 28 06:14:07 2024
Received: from localhost ([127.0.0.1]:44737 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sN8cI-00014Q-I3
	for submit <at> debbugs.gnu.org; Fri, 28 Jun 2024 06:14:07 -0400
Received: from lists.gnu.org ([209.51.188.17]:36676)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <manphiz@HIDDEN>) id 1sN8cG-00014G-Gk
 for submit <at> debbugs.gnu.org; Fri, 28 Jun 2024 06:14:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <manphiz@HIDDEN>) id 1sN8cG-0007oU-6U
 for bug-gnu-emacs@HIDDEN; Fri, 28 Jun 2024 06:14:04 -0400
Received: from mail-pj1-x1035.google.com ([2607:f8b0:4864:20::1035])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.90_1) (envelope-from <manphiz@HIDDEN>) id 1sN8cD-000878-JZ
 for bug-gnu-emacs@HIDDEN; Fri, 28 Jun 2024 06:14:03 -0400
Received: by mail-pj1-x1035.google.com with SMTP id
 98e67ed59e1d1-2c889d6995aso295718a91.3
 for <bug-gnu-emacs@HIDDEN>; Fri, 28 Jun 2024 03:14:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1719569639; x=1720174439; darn=gnu.org;
 h=mime-version:message-id:date:subject:to:from:from:to:cc:subject
 :date:message-id:reply-to;
 bh=AmTa6EPsXEhzrp/HFnp1oRdIbhTxQ79k1yCeTza+pFY=;
 b=hqolZ088QylaN4ezWQbOsLbrkLzdBgQq7/6Gon+5Kn6Jye7sB2LNO8xiKLJnv3g78L
 GxkEC128HxKi6Na7sWj1fLuZu4OcelYyMwneLIwL5FlzHkIBkakCmWellrtih+reytpc
 qmLIsAmM90cS29lvsOIB10vBL9KIKKpihCkrvScwCRJSsB8W4Bqx9rmIXV3c0uZGrd5U
 NNAhDpTgJ5jqax26I4Uj+Si/6tNSk1RQIS7yNg+N8EiX7yWJfhemAIBjs4wKNihIyHRV
 Qhy/0AtmjxkDwKjXMaQxJiu5hbtwsxHCr9RRfOoJUynQyZW0t9dHjUe+tsphQ0PArLBu
 l8FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1719569639; x=1720174439;
 h=mime-version:message-id:date:subject:to:from:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=AmTa6EPsXEhzrp/HFnp1oRdIbhTxQ79k1yCeTza+pFY=;
 b=DJAKwHL8xDF5EdXbT0QlgcZv8mZ/rAbHrZbmZI7t5b7nIEH0DcVTJc5ntMS6qp/w6T
 BTUArvrNIqM8g3ECNPlvtpd64wRaNh7TscuElrqyAAknh4p5lqtgf12Q37CYli8g/v6b
 v1ejRYnPD4GPBxACBWDkb0zuVA0MkpWA40IqUlK4d1P2apsRh46y59DHGOMcJjvXQe+4
 216lfD/NpIJ6u5ONts9wZvA22QnHMdjrTo6nF4GvVk9uOwNekxk27WgLRWcCm0wf3Zzs
 RiqXBCt9Twx51AkoRZOR5B2WmMEvn5mjdfetCCyhK7sypCN+WCcScvADpyvjUikiR8kF
 7gHA==
X-Gm-Message-State: AOJu0YyUOjRsidJpmw5pVJFuNqFMjS3oRr8944jUi9rLsDBK2/JlvDWT
 RgvoHW5dvLbDXdrjGatEPd7zkyRKsYW02UyrpVaD8jChZpOQ2D3q2E7SFA==
X-Google-Smtp-Source: AGHT+IH56CpnUHzjq/3rsxyN+qCxMPKTQmnO4ICmHLTLeA0jLooeczgqYo8sv5ZvJ7Sa03rMsQzw0A==
X-Received: by 2002:a17:90a:1286:b0:2a4:b831:5017 with SMTP id
 98e67ed59e1d1-2c861435644mr13002115a91.48.1719569639098; 
 Fri, 28 Jun 2024 03:13:59 -0700 (PDT)
Received: from debian-hx90 ([2603:8000:a400:cdc:2864:5a64:7050:2dac])
 by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2c91d3eb34bsm1244888a91.56.2024.06.28.03.13.58
 for <bug-gnu-emacs@HIDDEN>
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 28 Jun 2024 03:13:58 -0700 (PDT)
From: Xiyue Deng <manphiz@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 29.3; Sub-directory handling of ELPA package
Date: Fri, 28 Jun 2024 03:13:57 -0700
Message-ID: <875xtt8jdm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2607:f8b0:4864:20::1035;
 envelope-from=manphiz@HIDDEN; helo=mail-pj1-x1035.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
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: -2.3 (--)


Hi,

I'm opening a bug to continue the discussion from the emacs-devel
mailing list thread[1].

TL;DR I would like to understand how upstream would like to handle
sub-directories with ELisp source files as to whether to add them to
`load-path' recursively or not to determine the path forward for source
code organization.

Currently as observed, ELPA packages only get their root path added to
`load-path', but source code in sub-directories will still get
byte-compiled.  That is, for an ELPA package elpafoo with a nested
sub-directory of the following structure (installed through package.el):

,----
| ~/.config/emacs/elpa/elpafoo/
| ~/.config/emacs/elpa/elpafoo/elpafoo.el
| ~/.config/emacs/elpa/elpafoo/elpabar
| ~/.config/emacs/elpa/elpafoo/elpabar/elpabar.el
`----

only `~/.config/emacs/elpa/elpafoo' is added to `load-path', while both
elpafoo.el and elpabar.el will get byte-compiled.  Currently I don't
seem to find where this behavior is documented, so do give me a pointer
if it exists.

If this is not yet a policy, I wonder whether this will be the path
forward for `load-path' handling.  I see some pros of adding
sub-directories recursively, such as better source code organization so
that not all source code files need to reside in the root directory.
However, the downside is also obvious, such as unnecessary loading of
test sources as Michael pointed out in [2], or loading vendored code
that could cause conflicts (as I observed in the case of auctex), etc.

So, what would be the upstream or package.el maintainers' opinions on
how this should be handled?

Thanks in advance.

[1] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00658.html
[2] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg01039.html


In GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
 cairo version 1.16.0) of 2024-05-20, modified by Debian built on sbuild
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/libexec
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/29.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/29.3/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils
 --with-native-compilation --with-cairo --with-x=yes
 --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2
 -ffile-prefix-map=/build/reproducible-path/emacs-29.3+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2
XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  shell-dirtrack-mode: t
  mu4e-modeline-mode: t
  windmove-mode: t
  rcirc-track-minor-mode: t
  server-mode: t
  subword-mode: t
  bug-reference-prog-mode: t
  whitespace-mode: t
  yas-minor-mode: t
  xclip-mode: t
  global-treesit-auto-mode: t
  treemacs-project-follow-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: t
  treemacs-fringe-indicator-mode: t
  corfu-terminal-mode: t
  corfu-popupinfo-mode: t
  corfu-echo-mode: t
  global-corfu-mode: t
  corfu-mode: t
  activities-tabs-mode: t
  activities-mode: t
  fido-vertical-mode: t
  icomplete-vertical-mode: t
  icomplete-mode: t
  fido-mode: t
  override-global-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/elpa/debian-el-37.13/debian-autoloads hides /usr/share/emacs/site-lisp/elpa/gnuplot-0.8.1/debian-autoloads
/usr/share/emacs/site-lisp/elpa/magit-3.3.0/magit-section hides /usr/share/emacs/site-lisp/elpa/magit-section-3.3.0/magit-section

Features:
(shadow emacsbug mailalias vterm tramp tramp-loaddefs trampver
tramp-integration tramp-compat term ehelp vterm-module debian-copyright
goto-addr oc-basic org-element org-persist org-id avl-tree ol-eww eww
xdg mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview
doc-view image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi
org-link-doi shortdoc cl-print mu4e-speedbar speedbar ezimage dframe
mu4e-contrib eshell esh-cmd generator esh-ext esh-opt esh-proc esh-io
esh-arg esh-module esh-groups esh-util files-x mu4e-icalendar
gnus-icalendar org-capture org-refile icalendar diary-lib diary-loaddefs
url-http url-gw url-auth url-queue url-cache shr-color magit-extras
eglot external-completion array jsonrpc ert ewoc debug backtrace xref
pcase debian-changelog-mode debian-bug face-remap magit-bookmark
magit-submodule magit-obsolete magit-blame magit-stash magit-reflog
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-files magit-refs magit-status
magit magit-repos magit-apply magit-wip magit-log which-func imenu
magit-diff smerge-mode diff git-commit log-edit add-log magit-core
magit-autorevert magit-margin magit-transient magit-process with-editor
shell magit-mode transient magit-git magit-section gnus-async gnus-bcklg
gnus-ml gnus-topic cursor-sensor utf-7 dired-aux misearch multi-isearch
qp magit-utils crm jka-compr sort gnus-cite matlab matlab-scan
matlab-syntax matlab-compat mm-archive mail-extr textsec uni-scripts
idna-mapping ucs-normalize uni-confusable textsec-check help-fns
radix-tree nnfolder gnus-demon nnml ezgnus gnus-delay gnus-draft
gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp gnus-cache
nndraft nnmh mu4e-debian-hx90 mu4e mu4e-org org ob ob-tangle ob-ref
ob-lob ob-table ob-exp org-macro org-src ob-comint org-pcomplete
pcomplete org-list org-footnote org-faces org-entities noutline outline
ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold
org-fold-core org-keys oc org-loaddefs find-func org-version org-compat
org-macs format-spec mu4e-notification notifications mu4e-main smtpmail
mu4e-view mu4e-mime-parts cal-menu calendar cal-loaddefs mu4e-headers
mu4e-thread mu4e-actions mu4e-compose mu4e-draft gnus-msg gnus-art mm-uu
mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo
gnus-start gnus-dbus dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo
gnus-spec gnus-int gnus-range gnus-win gnus nnheader range mu4e-search
mu4e-lists mu4e-bookmarks mu4e-mark mu4e-message shr pixel-fill kinsoku
url-file svg xml dom flow-fill mule-util mu4e-contacts mu4e-update
mu4e-folders mu4e-context mu4e-query-items mu4e-server mu4e-modeline
mu4e-vars mu4e-helpers mu4e-config mu4e-window ido message sendmail
yank-media rfc822 mml mml-sec gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader mu4e-obsolete windmove
flyspell ispell gnutls network-stream puny nsm epa-file epa derived epg
rfc6068 epg-config rcirc parse-time iso8601 time-date term/xterm xterm
comp comp-cstr server cap-words superword subword vc-hg vc-git diff-mode
vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view pcvs-util vc
vc-dispatcher bug-reference disp-table whitespace yasnippet-snippets
yasnippet cus-edit cus-start wid-edit init zenburn-theme xclip
treesit-auto treesit treemacs-project-follow-mode treemacs-follow-mode
treemacs-rendering treemacs-annotations treemacs-async treemacs-visuals
treemacs-fringe-indicator pulse color treemacs-workspaces treemacs-dom
treemacs-icons treemacs-themes treemacs-scope treemacs-core-utils
treemacs-logging treemacs-customization pfuture inline ht s hl-line dash
keychain-environment exec-path-from-shell corfu-terminal popon
corfu-popupinfo corfu-echo corfu compat activities-tabs activities
persist bookmark pp edmacro kmacro advice icomplete cus-load
flymake-proc flymake project compile text-property-search comint
ansi-osc ansi-color ring warnings icons thingatpt cl-extra help-mode
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core
display-line-numbers autorevert filenotify
keychain-environment-autoloads treesit-auto-autoloads xclip-autoloads rx
info debian-el dired dired-loaddefs finder-inf package browse-url url
url-proxy url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 1552547 193601)
 (symbols 48 45285 63)
 (strings 32 201941 25320)
 (string-bytes 1 6355104)
 (vectors 16 124914)
 (vector-slots 8 2943117 153722)
 (floats 8 1149 2222)
 (intervals 56 55044 8833)
 (buffers 984 122))

-- 
Xiyue Deng