What is Pansymbolic? And why would you, Emacs package developer, care?

In Pansymbolic: Mapping all Emacs Lisp symbols you can read a lot about how.

But what does it look like?

And why would you, Emacs package developer, care?

Using Pansymbolic — the high-level view

You're writing a few Emacs packages. You've picked promising names for the packages and their symbols.

But do these symbols already exist somewhere?

Pansymbolic is a one-stop shop for Emacs Lisp symbols lookup — so that's where you go.

The updated sources are mirrored across a few forges. You pick a forge.

You download the database. You download the package that has functions to search the database.

You're ready to search.

Most searches are simply about trying to answer: does any package anywhere define symbols starting with these "prefixes"?

Depending on results, you do a few additional searches. Then you make decisions.

At some point, you're satisfied: your symbols are new, collisions are unlikely, you won't step on another author's toes. And you won't cause grief to users that would otherwise end up loading two packages that define the same symbols.

You name your package, functions, and variables. You tag it v0.1.0. It's ready to release.

You push the new repo to your favorite forge. You make it public.

You then submit the new repo link to Pansymbolic. You do that regardless of whether you'll eventually submit it to any package archivers.

Soon enough your package starts showing up in Pansymbolic queries. Others will know that your package exists, and which symbols it defines.

How does that improve things?

In several ways.

All symbols of all packages — searchable from a single place

Emacs Lisp symbols are defined in several places:

in primitives
in Emacs native packages
in all packages in the three main *ELPAs
in all packages independently distributed through git repositories

That's inconvenient.

Moreover, package names are by themselves insufficient for guessing the availability of symbols.

That's also inconvenient.

Pansymbolic reliably and independently aggregates all the information in one place.

Easy to look up and submit

Pansymbolic makes available both the database and querying tools. It's easy and fast to get the information that you, Emacs package developer, want. It's easy to submit your package.

Fewer unnecessary submissions to archivers

Authors may feel perfectly fine distributing a package directly from its git repository. Yet they may end up submitting it to an archiver for no reason other than a felt need to "register its namespace".

We can do better.

Pansymbolic registers a package and its symbols quickly, painlessly, and universally. Every Emacs Lisp package is welcome. As a result, fewer packages are unnecessarily sent to archivers. This saves your time and theirs.

Of course, you may still eventually submit your package to an archiver, if you believe it's worth it, for whatever other reasons you may have: reviewing, distribution, discoverability, package-requirability, etc.

Lower chance of collisions

Given its continuously improving high coverage and the reliability of queries, you have confidence that your choice is good: your package's symbols aren't likely to collide with those of previous packages.

Moreover, by registering your package as soon as it's published, you inform other authors immediately, which in turn prevents their packages from colliding with yours. This is good for both of you, and for all users of both packages.

Everybody knows where to look — and visibility is high.

Get started now!

Bummer. You can't. There's no database yet.

Besides the design, I wrote two packages that address "the middle" (data conversions and functional queries).

We need "the beginning" (symbols extraction from all packages) and "the end" (making the resulting database available).

We also need a process to keep that updated.

And we need updated policies and guidance, because the issue isn't only technological. (The database gives you answers. But when the case is unclear, what will you take into account to decide?)

Next steps

Next steps would be:

[ ] reliably solve symbols extraction for one package (as tarball or git repo)
[ ] apply that to all native packages
[ ] apply that to all archivers' packages
[ ] create a first, static version of the database — and make it available
[ ] test querying tools on that database version
[ ] come up with a process to receive submissions of independent packages
[ ] start receiving submissions of independent packages
[ ] define process to automatically add new packages that show up in archivers
[ ] define policy of how often to "refresh" packages (requery symbols from already-added packages)
[ ] build an API for remote search (maybe; if someone wants to maintain it; not strictly necessary)

Does any of these sound like you? Read more, get involved.