From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Reitter Newsgroups: gmane.emacs.devel Subject: Re: package.el Date: Mon, 21 May 2007 23:43:24 +0100 Message-ID: References: <2cd46e7f0705101124r72000f78xdf05d18ca815ca57@mail.gmail.com> <17991.47259.210100.801472@localhost.localdomain> <85d50wq6a9.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1179787428 14073 80.91.229.12 (21 May 2007 22:43:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 21 May 2007 22:43:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: tromey@redhat.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 22 00:43:47 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HqGbK-000512-T9 for ged-emacs-devel@m.gmane.org; Tue, 22 May 2007 00:43:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HqGbK-0007dk-FV for ged-emacs-devel@m.gmane.org; Mon, 21 May 2007 18:43:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HqGbG-0007dF-MW for emacs-devel@gnu.org; Mon, 21 May 2007 18:43:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HqGbF-0007cw-4v for emacs-devel@gnu.org; Mon, 21 May 2007 18:43:34 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HqGbF-0007cs-07 for emacs-devel@gnu.org; Mon, 21 May 2007 18:43:33 -0400 Original-Received: from ug-out-1314.google.com ([66.249.92.174]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HqGbE-0000jU-Ez for emacs-devel@gnu.org; Mon, 21 May 2007 18:43:32 -0400 Original-Received: by ug-out-1314.google.com with SMTP id j3so69018ugf for ; Mon, 21 May 2007 15:43:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=J/tYNGPRVM5KBsOTnSDzKOydimK6JcB1W4WoYZ1c8e5C32OoN2uSfC+qD+fW/TJ87hK2AyExu18J+2CayggE77a1/RS24zDxhNuk7BCrjYoR0UZnubwKC4xZ8gxRaA4NlG1h0JigMkVhEcO44/Eu/xzSu/CUhhgIIkt7RGvIRYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=ozq5Jizx6UQ0WnVX0oYoSxKhPTXgkZoHL7S5vZk2b2/LOSl9As1o40JegzOteHHtpVLb/rt4RgLmsnK4MR9Yt0pok6Oj/PZozPaNJKFY1Tpii22QSpJRG9Q+IwsKXCiD9+EIiOhK/2ittnGRqX11rMGVuAgFMyjBA3mWSUknA5I= Original-Received: by 10.67.10.18 with SMTP id n18mr97828ugi.1179787410494; Mon, 21 May 2007 15:43:30 -0700 (PDT) Original-Received: from ?10.5.5.200? ( [84.9.228.229]) by mx.google.com with ESMTP id b30sm984984ika.2007.05.21.15.43.28; Mon, 21 May 2007 15:43:29 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.752.2) X-detected-kernel: Linux 2.4-2.6 (Google crawlbot) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:71550 Archived-At: On 21 May 2007, at 18:40, Tom Tromey wrote: > David> *scratch* is not guaranteed to be in emacs-lisp-mode. So C-j > might > David> not work. M-x eval-region would! > > I wasn't aware of this. Is this a common situation? Those > instructions are intended for people who know very little about Emacs; > are they likely to have changed the mode for *scratch*? default-major-mode's default value is text-mode in Aquamacs. *scratch* is in text-mode by default. > Yes, I agree. I don't know much about custom (my last emacs lisp > hacking experience predates the existence of custom -- sad but true). > But I will learn and I'll make the appropriate fix. > > However, for the installer, I think this is an ok choice. Well, in a distribution, this is what one wants to customize - simply because ~/.emacs.d is not a [standard] directory on all operating systems. I don't know what Windows does, but on the Mac, such extensions go into ~/Applications/Application Support/Emacs/... - which is something a CVS (GNU) Emacs doesn't do. But a distribution of GNU Emacs (such as Aquamacs) knows these directories. > and use features like this probably won't have much trouble hand > installing package.el. Yes, if it's a standard package that provides a new feature - sure no problem. That's what would be included in a distro anyways. > Yes. package.el knows a bit about which packages are shipped as part > of Emacs. This supports one of the use cases I was interested in, > something I've run into a reasonable number of times. OK, please don't forget cases where a distribution installs additional packages. Both distributions on the Mac do that, and I presume the Windows binaries come with some add-ons, too. And you, yourself, mentioned Fedora's dislike for Tetris, etc. > In package.el this is solved by knowing the versions of large packages > which are included in Emacs. This list isn't complete though -- known > bug. Yes, bug. I would check the versions of all installed packages at compile time (install time), going through Emacs' load path. Or, perhaps better, you check for installed versions just when you actually need to know, i.e., when the user wants to install another package. As a distributor, I would not enable a feature that will slow down the application startup. > I suppose my ideal situation here would be for distros to support > package.el directly (my real ideal was to get this into Emacs itself > but that is looking less likely :-). It's more realistic to make package.el work in the way Emacs already finds and loads its packages, rather than requiring distributors to maintain a separate database of file versions (even though that would be a sensible thing to do). This could be done via a standard symbol `feature-version' where "feature" stands for the name of the feature that is `provide'd, or via the subfeatures argument to `provide'. I don't know what is already in place in package.el.