From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#13291: The package description buffer needs an URL button Date: Tue, 12 Mar 2013 15:49:36 +0400 Message-ID: <513F1650.6070700@yandex.ru> References: <50DDAF17.7020602@yandex.ru> <50F26A91.1090905@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1363089022 20346 80.91.229.3 (12 Mar 2013 11:50:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Mar 2013 11:50:22 +0000 (UTC) Cc: 13291@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 12 12:50:46 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1UFNjA-0000BE-Bq for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2013 12:50:44 +0100 Original-Received: from localhost ([::1]:44606 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFNio-0001rK-3X for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Mar 2013 07:50:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:41546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFNig-0001ox-IQ for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 07:50:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UFNiV-0003KV-4o for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 07:50:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43896) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UFNiU-0003Hq-P3 for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 07:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UFNjR-0000l8-Lb for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2013 07:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Mar 2013 11:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13291 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13291-submit@debbugs.gnu.org id=B13291.13630890492896 (code B ref 13291); Tue, 12 Mar 2013 11:51:01 +0000 Original-Received: (at 13291) by debbugs.gnu.org; 12 Mar 2013 11:50:49 +0000 Original-Received: from localhost ([127.0.0.1]:48005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFNjE-0000ke-U9 for submit@debbugs.gnu.org; Tue, 12 Mar 2013 07:50:49 -0400 Original-Received: from mail-la0-f53.google.com ([209.85.215.53]:37636) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UFNjB-0000kQ-A5 for 13291@debbugs.gnu.org; Tue, 12 Mar 2013 07:50:47 -0400 Original-Received: by mail-la0-f53.google.com with SMTP id fr10so5097594lab.12 for <13291@debbugs.gnu.org>; Tue, 12 Mar 2013 04:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-antivirus:x-antivirus-status; bh=lTxm10/KeaIVFwzVoqmq/CXx8frIYOpL9Ef2ANgqHg4=; b=daYx2KvN2rEWL/ZOrzr531gDxloUIYNZhC1hgSWYF52MrbBhWr7Ee90lhlaXkkSHKj F77YSnL9OqaPqqh/QHhNK6L1TTm5DxS01ACn760r9YQ3lOABO+EoXyWbkPEl8JkakqPQ jftPH1l9tDk9D0WzASnGXrVV1oEAqW4xlmj9gnnAxO5GgoinjzU16hEMmUqaCWF0SfZs UQ4M4dkHajGCoAH9OALkZZVeUJisn7yqJGIBIuiGZpAAXVY4OxGYxK0b/+pj8BHzWgri vzOrI1u0zbN5DJbWYQwDM6dEvFwPe2XXytQQsS2RzdtccMhniS6kpiPOHrR1pcLgeCj0 Fe8A== X-Received: by 10.112.16.137 with SMTP id g9mr5968109lbd.119.1363088979525; Tue, 12 Mar 2013 04:49:39 -0700 (PDT) Original-Received: from [127.0.0.1] ([178.252.98.87]) by mx.google.com with ESMTPS id xw14sm9089985lab.6.2013.03.12.04.49.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 04:49:38 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 In-Reply-To: X-Antivirus: avast! (VPS 130312-0, 12.03.2013), Outbound message X-Antivirus-Status: Clean X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:72368 Archived-At: On 11.03.2013 21:40, Stefan Monnier wrote: >> And here's the updated patch for package.el, with saving the new metadata >> to -pkg.el file when a single-file package is being installed, and with >> support for it in `package-install-file'. > > Sorry for taking so long. Here are some comments. Not a problem, I rather expected some other developers familiar with this package to chime in. >> +(require 'cl-lib) > > AFAICT, you only do that for cl-cddddr, but: > - cl-cddddr only requires cl-lib at compile-time. > - "nthcdr 4" is both shorter and faster. Thanks, good to know. I wasn't aware that `nthcdr' is implemented in C. >> -The vector DESC has the form [VERSION-LIST REQS DOCSTRING]. >> +The vector DESC has the form [VERSION-LIST REQS DOCSTRING META]. > [...] >> + META is a property list mapping metadata keywords to values. > > VERSION-LIST, REQS, and DOCSTRING are also metadata, so I'd call the new > entry something like EXTRA or EXTRA-PROPS rather than META. Sounds good. > Also, I'd personally use an alist rather than a plist, tho it's largely > a question of taste (I prefer alist because they have a bit more > structure, which in turn lets you use things like mapcar, memq, dolist, > ... on them). > [ From a theoretical efficiency viewpoint they are also half as deep as > plists, so in an "ideal" PRAM world, they'd be about twice as fast, > although in reality I doubt there is any measurable difference. ] Hmm, I kinda assumed that the simpler structure would result in better, not worse, theoretical performance. Food for thought. But I'm not really sure if we're ever going to want to iterate over the extra properties. Right now, where it's accessed, the change to alist will mostly mean going from (plist-get (package-desc-meta desc) :homepage) to (cdr (assoc :homepage (package-desc-meta desc))) which is not as nice. >> (defsubst package-desc-kind (desc) >> "Extract the kind of download from an archive package description vector." >> + (plist-get (package-desc-meta desc) :kind)) >> + >> +(defsubst package-desc-meta (desc) >> + "Extract the metadata property list from a package description vector." >> (aref desc 3)) > > Hmm... does that mean that the 4th field of each vector in > `archive-contents' is changed from holding either `tar' or `single' to > holding a plist? Yes. > Why not add a 5th field instead? It actually has a 5th field already (containing the name of the repository). This is a bit complicated, because we also have `package-alist', its entries don't have the last two elements, and we want the homepage url to be available in both. But I guess we could push the new element before `kind' instead. This may be moot now, now that we have the updated Daniel's defstruct-based rewrite, which uses struct accessor functions here, so adding another slot would be the way to go. (Since it has a test suite, merging this patch on top of it should be easier than going the other way around). >> (defun define-package (name-string version-string >> &optional docstring requirements >> - &rest _extra-properties) >> + &rest extra-properties) > [...] >> -EXTRA-PROPERTIES is currently unused." >> +EXTRA-PROPERTIES is a property list mapping additional metadata >> +keywords (e.g. `:homepage') to values." > > I guess here I agree that a plist is more convenient for the > package maintainer. One of the things you haven't commented on is that the vectors in the archive-contents file are of variable length with this proposal. Should (cl-lib . [(0 2) nil "Prefixed!" single :homepage "http://foo"]) turn into (cl-lib . [(0 2) nil "Prefixed!" single (:homepage "http://foo")]) or maybe (cl-lib . [(0 2) nil "Prefixed!" single (:homepage . "http://foo")]) ?