From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is there a need for a module system Date: Sun, 30 Oct 2022 13:38:35 +0200 Message-ID: <83h6zlfsn8.fsf@gnu.org> References: <978489cd-efda-56c6-5a3f-681e10e64378@gmail.com> <83leoxfusf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3993"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 30 12:39:46 2022 Return-path: Envelope-to: ged-emacs-devel@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 1op6fJ-0000rd-OJ for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Oct 2022 12:39:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1op6eY-0005yR-Be; Sun, 30 Oct 2022 07:38:58 -0400 Original-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 ) id 1op6eW-0005yK-NN for emacs-devel@gnu.org; Sun, 30 Oct 2022 07:38:57 -0400 Original-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 ) id 1op6eU-0004Ky-Kt; Sun, 30 Oct 2022 07:38:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=10KqfqGLmWfhJENFyd4x1+7B5uLOijJkSbnwHksYMs8=; b=SE5/02gt/SozkCWKTb87 r4wHNnllCGTgdgUkJblz8+jaze8SI9fsAa0qGc7FgunSjGrwipHaENRyHq9STpYts+MN+n8n8d2Ef XJBIglGkb1YErV2N3+mgUFVgLHPRO7ZVH05uJht4MgVGI3dhPeEFGUmcfaNmow0uvjuEqE0OVNLz9 lAaBYVHPPc8NLQEjffd7GwuqCBgHJrCtM3Y4u0wcsnJacPko9cFVdYROOaoUsSrxCXEv7S/MeoJO2 guV7QMyWXK7s3/yVv4ZkDHIJnzjjGbzdlQLj14D1X6vy+bpMVwkL6tx4wlcK9CPkdXyC8P+Ph/ymw ApcJC8qcwN2vHw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1op6eU-0005TU-1H; Sun, 30 Oct 2022 07:38:54 -0400 In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Sun, 30 Oct 2022 12:24:15 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "Emacs-devel" Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:298806 Archived-At: > From: Gerd Möllmann > Cc: tomas@tuxteam.de, emacs-devel@gnu.org > Date: Sun, 30 Oct 2022 12:24:15 +0100 > > The reason being that I think one cannot look at specific Lisp programs > like gnus or org in isolation. If I look at Melpa, it says it has 5299 > packages. Add GNU Elpa, for which I couldn't readily find the number, > and Emacs' Lisp, and subtract what's in common. That's pretty large > from my POV. Does someone really use 5299 packages (or any number close to that) in the same Lisp program? IOW, why should I care how many unused packages lie around on my disk? As long as I don't have them in my program, they will never cause any trouble. > I'd rather ask is that a good enough solution? Can we do better? Is it > worth the effort? Can it be done in the first place? Does it perhaps > enable additional things? All good questions, but they must be considered in some relevant context, IMO. "Good enough solution" for what problems and what purposes? Emacs is enormously large. Already there's not a single person who can be familiar with everything we have, even in the core packages, like subr.el, simple.el, etc. Or even come close to that. Myself and Lars are learning something new almost every day. We definitely miss some problems that get introduced and we are definitely doing an imperfect job of keeping Emacs clean, due to this enormity alone. Making Emacs even larger and more complex in these conditions needs very good reasons in my book. So the question of need are very pertinent, IMO.