Re: Merging Finder into package mechanism

[Juri Linkov <juri@jurta.org>]

>> 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.