From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Finding packages to enable by default Date: Sun, 01 Dec 2013 14:01:34 -0500 Message-ID: References: <8761ra7uq3.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1385924510 2017 80.91.229.3 (1 Dec 2013 19:01:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Dec 2013 19:01:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Tom Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 01 20:01:55 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VnCHC-0001vT-Tw for ged-emacs-devel@m.gmane.org; Sun, 01 Dec 2013 20:01:55 +0100 Original-Received: from localhost ([::1]:60813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnCHC-0001Nm-IN for ged-emacs-devel@m.gmane.org; Sun, 01 Dec 2013 14:01:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnCH2-0001NW-PY for emacs-devel@gnu.org; Sun, 01 Dec 2013 14:01:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VnCGt-00019P-T7 for emacs-devel@gnu.org; Sun, 01 Dec 2013 14:01:44 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:20285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VnCGt-00019J-PB for emacs-devel@gnu.org; Sun, 01 Dec 2013 14:01:35 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFMCox4/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kMYdtBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFFMCox4/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kMYdtBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="40850858" Original-Received: from 76-10-140-120.dsl.teksavvy.com (HELO pastel.home) ([76.10.140.120]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 01 Dec 2013 14:01:34 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7678864AEB; Sun, 1 Dec 2013 14:01:34 -0500 (EST) In-Reply-To: (Tom's message of "Sun, 1 Dec 2013 16:42:21 +0000 (UTC)") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165990 Archived-At: >> I think you should filter out the ones that appear in `features' after >> "emacs -Q". > This will hardly make a dent in the results, becase there 6000 items > in the list and emacs with -Q returns only 110 features for me. Of course, "emacs -Q" has different features depending on the particular Emacs you use, so we can trim it down a bit more this way, but if we look at your sample: > (x . 268) > (x-dnd . 267) > (x-win . 267) > (x-toolkit . 264) > (newcomment . 264) > (ring . 259) > (advice . 257) > (font-render-setting . 253) > (macroexp . 252) > (dbusbind . 249) > (cl . 246) > (comint . 243) > (tabulated-list . 241) > (easy-mmode . 239) > (kmacro . 236) > (edmacro . 232) > (gtk . 231) > (byte-compile . 230) > (bytecomp . 229) > (byte-opt . 229) > ... We see that things like `x-win', `gtk', `macroexp', and `newcomment' might be trimmed with a more careful handling of "emacs -Q". But the bulk of the "spurious" features that remain is made of packages which "can't be *enabled*". > These seem fairly basic stuff. Indeed. > I should mention that I use 24.1.1. Is it possible that the current > emacs has a much longer features list with -Q? Longer, yes, much longer, no. I can't think of an easy to way to characterize a feature which can be "enabled". At least, not a way amenable to mechanization. So I think a human will have to go through the list and try to classify the various features by hand. Tho, maybe we could start by focusing on minor modes: go through the list of packages, see if they correspond to an Elisp file, search the file with a `define-minor-mode'. It wouldn't have found uniquify, and it will find packages which simply use minor-modes "internally", but that might be a start. Stefan