[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Merging Finder into package mechanism
From: |
Juri Linkov |
Subject: |
Re: Merging Finder into package mechanism |
Date: |
Tue, 31 Aug 2010 23:39:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (x86_64-pc-linux-gnu) |
>> It's better to have all package information in one place.
>> I suggest not to lose information that was in finder-inf.el.
>
> It's a bit problematic. Moving the keywords into package--builtins
> necessitates a change in the archive-contents file format, which means
> incompatibility with the old elpa repository.
Does the archive-contents file format have a fixed number of fields?
Too bad. For extensibility it would be better to reserve one field
for an alist of additional key/value pairs like
(ediff .
[(2 81 4) nil "a comprehensive visual interface to diff & patch"
((keywords . (comparing merging patching tools unix)))])
or
(ediff
[(2 81 4) nil "a comprehensive visual interface to diff & patch"]
((keywords . (comparing merging patching tools unix))))
> This scheme also forces key lookup to iterate over all packages, which
> seems inelegant.
You can create the hash table during reading of finder-inf.el.
> The scheme I came up with is to put the keywords into a hash table, also
> stored in finder-inf.el (further down in the file), which maps keywords
> to package lists. True, this is not 100% satisfactory.
A hash table is an optimization. I think complete information about
every package should be in the same place to help libraries to process
package information instead of relying on two separate variables
`package--builtins' (where double dashes in the variable name mean
it's an internal variable) and `finder-keywords-hash' whose different
name prefixes (`package-' and `finder-') are misleading and suggest that
they are unrelated.
Re: Merging Finder into package mechanism, Chong Yidong, 2010/08/29